- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] geneve: fix header validation in geneve[6]_xmit_skb
by Dong Chenchen 04 Jun '24

04 Jun '24

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.216 commit 10204df9beda4978bd1d0c2db0d8375bfb03b915 category: bugfix bugzilla: 190035, https://gitee.com/src-openeuler/kernel/issues/I9QRAK CVE: CVE-2024-35973 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit d8a6213d70accb403b82924a1c229e733433a5ef ] syzbot is able to trigger an uninit-value in geneve_xmit() [1] Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb->protocol. If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol, pskb_inet_may_pull() does nothing at all. If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected. Add skb_vlan_inet_prepare() to perform a complete mac validation. Use this in geneve for the moment, I suspect we need to adopt this more broadly. v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types. Link: https://lore.kernel.org/netdev/20240404100035.3270a7d5@kernel.org/ v2,v3 - Addressed Sabrina comments on v1 and v2 Link: https://lore.kernel.org/netdev/Zg1l9L2BNoZWZDZG@hog/ [1] BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Fixes: d13f048dd40e ("net: geneve: modify IP header check in geneve6_xmit_skb and geneve_xmit_skb") Reported-by: syzbot+9ee20ec1de7b3168db09(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/000000000000d19c3a06152f9ee4@google.com/ Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: Phillip Potter <phil(a)philpotter.co.uk> Cc: Sabrina Dubroca <sd(a)queasysnail.net> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Reviewed-by: Phillip Potter <phil(a)philpotter.co.uk> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/geneve.c | 4 ++-- include/net/ip_tunnels.h | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 2 deletions(-) diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c index 081939cb420b..65722f844f8a 100644 --- a/drivers/net/geneve.c +++ b/drivers/net/geneve.c @@ -893,7 +893,7 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev, __be16 sport; int err; - if (!pskb_inet_may_pull(skb)) + if (!skb_vlan_inet_prepare(skb)) return -EINVAL; sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true); @@ -990,7 +990,7 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev, __be16 sport; int err; - if (!pskb_inet_may_pull(skb)) + if (!skb_vlan_inet_prepare(skb)) return -EINVAL; sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true); diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h index 1ddd401a8981..219b407a6607 100644 --- a/include/net/ip_tunnels.h +++ b/include/net/ip_tunnels.h @@ -333,6 +333,39 @@ static inline bool pskb_inet_may_pull(struct sk_buff *skb) return pskb_network_may_pull(skb, nhlen); } +/* Variant of pskb_inet_may_pull(). + */ +static inline bool skb_vlan_inet_prepare(struct sk_buff *skb) +{ + int nhlen = 0, maclen = ETH_HLEN; + __be16 type = skb->protocol; + + /* Essentially this is skb_protocol(skb, true) + * And we get MAC len. + */ + if (eth_type_vlan(type)) + type = __vlan_get_protocol(skb, type, &maclen); + + switch (type) { +#if IS_ENABLED(CONFIG_IPV6) + case htons(ETH_P_IPV6): + nhlen = sizeof(struct ipv6hdr); + break; +#endif + case htons(ETH_P_IP): + nhlen = sizeof(struct iphdr); + break; + } + /* For ETH_P_IPV6/ETH_P_IP we make sure to pull + * a base network header in skb->head. + */ + if (!pskb_may_pull(skb, maclen + nhlen)) + return false; + + skb_set_network_header(skb, maclen); + return true; +} + static inline int ip_encap_hlen(struct ip_tunnel_encap *e) { const struct ip_tunnel_encap_ops *ops; -- 2.25.1

2 1

[PATCH OLK-5.10 v7 00/11] Memory access profiler(SPE) driven NUMA balancing
by Ze Zuo 04 Jun '24

04 Jun '24

Hi, In Arm processors, there is a hardware PMU (Performance Monitoring Unit) facility called Statistical Profiling Extension (SPE) that can gather memory access metrics. In this patchset, SPE is exploited as an access information sampling approach to drive NUMA balancing. This sampling approach is introducedto replace the method based on address space scanning and hint faults with the access information provided by the hardware. With this, it is no longer necessary for NUMA balancing to scan over the address space periodically and rely on task-to-page association built by NUMA hint faults. Instead, the access samples obtained from hardware PMU are fed to NUMA balancing as equivalents to page fault. Except for the replaced sampling approach, the rest of the NUMA balancing policy is retained to do pages and tasks migrations according to the samples. Profiling based on SPE is an valid alternative sampling approach in NUMA balancing for the optimal page and task placement. This can be also extended to other architectures as long as there is a hardware PMU that supports memory access profiling. An abstract layer mem_sampling is introduced to reserve support for other kernel features and different types of hardware PMU. To help evaluate performance of this approach in system, syctl interfaces are added to enable/disable hardware mem sampling. NUMA balancing sampling approach can be also switched back to hint-faults- based approach dynamically. TODOs Currently, SPE for NUMA balance does not support PMD-level page migration, but it will be supported in later version. Changes since v6: -- clean code on spe.c, arm_spe_pmu.c. Changes since v5: -- Modify perf and mem_sampling compatibility logic. -- Introduce cmdline mem_sampling_on to use mem_sampling. Changes since v4: -- some patch check warning fixs, no functional change. Changes since v3: -- some clean code, no functional change. Changes since v2: -- clean code and commit fixs, no functional change. Changes since v1: -- clean code, no functional change. Ze Zuo (11): drivers/arm/spe: In-kernel SPE driver for page access profiling mm: Add PMU based memory sampling abstract layer mm/mem_sampling.c: Add controlling interface for mem_sampling sched: Enable per-process mem_sampling from sched switch path mm/mem_sampling.c: Drive NUMA balancing via mem_sampling access data mm/mem_sampling.c: Add controlling interface for mem_sampling on numa balance tracing, numa balance: add trace events for numa data caused by mem_sampling driver/arm/spe: making mem_sampling and perf mutually exclusive with spe driver tracing, mem-sampling-sample: Adding tracking events to hardware-sampled page access samples/bpf: Add program for memory access by spe config: Enable memory sampling based pmu for numa balance by default arch/arm64/configs/openeuler_defconfig | 3 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/arm/Kconfig | 2 + drivers/arm/spe/Kconfig | 10 + drivers/arm/spe/Makefile | 2 + drivers/arm/spe/spe-decoder/Makefile | 2 + drivers/arm/spe/spe-decoder/arm-spe-decoder.c | 213 +++++ drivers/arm/spe/spe-decoder/arm-spe-decoder.h | 74 ++ .../arm/spe/spe-decoder/arm-spe-pkt-decoder.c | 227 +++++ .../arm/spe/spe-decoder/arm-spe-pkt-decoder.h | 153 ++++ drivers/arm/spe/spe.c | 805 ++++++++++++++++++ drivers/arm/spe/spe.h | 120 +++ drivers/perf/arm_pmu_acpi.c | 2 +- drivers/perf/arm_spe_pmu.c | 6 + include/linux/mem_sampling.h | 106 +++ include/trace/events/kmem.h | 80 ++ kernel/sched/core.c | 2 + kernel/sched/fair.c | 11 + mm/Kconfig | 24 + mm/Makefile | 1 + mm/mem_sampling.c | 476 +++++++++++ samples/bpf/spe/Makefile | 26 + samples/bpf/spe/Makefile.arch | 47 + samples/bpf/spe/README.md | 0 samples/bpf/spe/spe-record.bpf.c | 40 + samples/bpf/spe/spe-record.h | 47 + samples/bpf/spe/spe-record.user.c | 116 +++ 28 files changed, 2597 insertions(+), 1 deletion(-) create mode 100644 drivers/arm/Kconfig create mode 100644 drivers/arm/spe/Kconfig create mode 100644 drivers/arm/spe/Makefile create mode 100644 drivers/arm/spe/spe-decoder/Makefile create mode 100644 drivers/arm/spe/spe-decoder/arm-spe-decoder.c create mode 100644 drivers/arm/spe/spe-decoder/arm-spe-decoder.h create mode 100644 drivers/arm/spe/spe-decoder/arm-spe-pkt-decoder.c create mode 100644 drivers/arm/spe/spe-decoder/arm-spe-pkt-decoder.h create mode 100644 drivers/arm/spe/spe.c create mode 100644 drivers/arm/spe/spe.h create mode 100644 include/linux/mem_sampling.h create mode 100644 mm/mem_sampling.c create mode 100644 samples/bpf/spe/Makefile create mode 100644 samples/bpf/spe/Makefile.arch create mode 100644 samples/bpf/spe/README.md create mode 100644 samples/bpf/spe/spe-record.bpf.c create mode 100644 samples/bpf/spe/spe-record.h create mode 100644 samples/bpf/spe/spe-record.user.c -- 2.33.0

2 12

[PATCH openEuler-1.0-LTS 0/1] fix CVE-2021-47283
by Lin Yujun 04 Jun '24

04 Jun '24

*** BLURB HERE *** Íñigo Huguet (1): net:sfc: fix non-freed irq in legacy irq mode drivers/net/ethernet/sfc/nic.c | 1 + 1 file changed, 1 insertion(+) -- 2.34.1

2 2

[PATCH openEuler-22.03-LTS-SP1 0/1] fix CVE-2021-47558
by Hongbo Li 04 Jun '24

04 Jun '24

Fix CVE-2021-47558. Yannick Vignon (1): net: stmmac: Disable Tx queues when reconfiguring the interface drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.34.1

2 2

[PATCH OLK-5.10 0/1] fix CVE-2021-47558
by Hongbo Li 04 Jun '24

04 Jun '24

Fix CVE-2021-47558. Yannick Vignon (1): net: stmmac: Disable Tx queues when reconfiguring the interface drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.34.1

2 2

[PATCH OLK-5.10] virtio-blk: fix implicit overflow on virtio_max_dma_size
by Li Nan 04 Jun '24

04 Jun '24

From: zhenwei pi <pizhenwei(a)bytedance.com> mainline inclusion from mainline-v6.7-rc1 commit fafb51a67fb883eb2dde352539df939a251851be category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4LS CVE: CVE-2023-52762 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The following codes have an implicit conversion from size_t to u32: (u32)max_size = (size_t)virtio_max_dma_size(vdev); This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead. Signed-off-by: zhenwei pi <pizhenwei(a)bytedance.com> Message-Id: <20230904061045.510460-1-pizhenwei(a)bytedance.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> Conflicts: drivers/block/virtio_blk.c [ Context conflict. ] Signed-off-by: Li Nan <linan122(a)huawei.com> --- drivers/block/virtio_blk.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index e121a620d201..c4ffa7b8d77c 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -702,6 +702,7 @@ static int virtblk_probe(struct virtio_device *vdev) struct virtio_blk *vblk; struct request_queue *q; int err, index; + size_t max_dma_size; u32 v, blk_size, max_size, sg_elems, opt_io_size; u16 min_io_size; @@ -810,7 +811,8 @@ static int virtblk_probe(struct virtio_device *vdev) /* No real sector limit. */ blk_queue_max_hw_sectors(q, -1U); - max_size = virtio_max_dma_size(vdev); + max_dma_size = virtio_max_dma_size(vdev); + max_size = max_dma_size > U32_MAX ? U32_MAX : max_dma_size; /* Host can optionally specify maximum segment size and number of * segments. */ -- 2.39.2

2 1

[PATCH OLK-5.10] mmc: sdhci-msm: pervent access to suspended controller
by Cai Xinchen 04 Jun '24

04 Jun '24

From: Mantas Pucka <mantas(a)8devices.com> mainline inclusion from mainline-v6.9-rc6 commit f8def10f73a516b771051a2f70f2f0446902cb4f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9TMCJ CVE: CVE-2024-36029 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly. Cc: stable(a)vger.kernel.org Fixes: 67e6db113c90 ("mmc: sdhci-msm: Add pm_runtime and system PM support") Signed-off-by: Mantas Pucka <mantas(a)8devices.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Link: https://lore.kernel.org/r/20240321-sdhci-mmc-suspend-v1-1-fbc555a64400@8dev… Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Conflicts: drivers/mmc/host/sdhci-msm.c [Because commit c7eed31e235ce not merged, there is no sdhci_msm_ice_resume.] Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- drivers/mmc/host/sdhci-msm.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index 3366956a4ff1..9a844288bb6f 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -2571,6 +2571,11 @@ static __maybe_unused int sdhci_msm_runtime_suspend(struct device *dev) struct sdhci_host *host = dev_get_drvdata(dev); struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host); + unsigned long flags; + + spin_lock_irqsave(&host->lock, flags); + host->runtime_suspended = true; + spin_unlock_irqrestore(&host->lock, flags); /* Drop the performance vote */ dev_pm_opp_set_rate(dev, 0); @@ -2585,6 +2590,7 @@ static __maybe_unused int sdhci_msm_runtime_resume(struct device *dev) struct sdhci_host *host = dev_get_drvdata(dev); struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host); struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host); + unsigned long flags; int ret; ret = clk_bulk_prepare_enable(ARRAY_SIZE(msm_host->bulk_clks), @@ -2600,6 +2606,10 @@ static __maybe_unused int sdhci_msm_runtime_resume(struct device *dev) dev_pm_opp_set_rate(dev, msm_host->clk_rate); + spin_lock_irqsave(&host->lock, flags); + host->runtime_suspended = false; + spin_unlock_irqrestore(&host->lock, flags); + return ret; } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS v2] bcache: avoid oversized read request in cache missing code path
by Xiang Yang 04 Jun '24

04 Jun '24

From: Coly Li <colyli(a)suse.de> mainline inclusion from mainline-v5.13-rc6 commit 41fe8d088e96472f63164e213de44ec77be69478 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4I7 CVE: CVE-2021-47275 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Here s->d->cache_miss() is the call backfunction pointer initialized as cached_dev_cache_miss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data. Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below, 1) BUG_ON() inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_slab(), [code block 3] 51 default: 52 BUG(); 53 return NULL; All the above panics are original from cached_dev_cache_miss() by the oversized parameter 'sectors'. Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insert_bio_sectors by the following lines of code, [code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following lines of code, [code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block. And the bio sending to backing device for the missing data is allocated with hint from s->insert_bio_sectors by the following lines of code, [code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block. Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replace_key is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 }) Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is very probably to be larger than (1<<16) - 1, which makes the bkey size calculation in code block 5 is overflowed. In one bug report the value of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors' results the overflowed s->insert_bio_sectors in code block 4, then makes size field of s->iop.replace_key to be 0 in code block 5. Then the 0- sized s->iop.replace_key is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key); Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey size check BUG_ON() in code block 2, and causes the kernel panic 1). Another kernel panic is from code block 6, is by the bvecs number oversized value s->insert_bio_sectors from code block 4, min(sectors, bio_sectors(bio) + reada) There are two possibility for oversized reresult, - bio_sectors(bio) is valid, but bio_sectors(bio) + reada is oversized. - sectors < bio_sectors(bio) + reada, but sectors is oversized. From a bug report the result of "DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS)" from code block 6 can be 344, 282, 946, 342 and many other values which larther than BIO_MAX_VECS (a.k.a 256). When calling bio_alloc_bioset() with such larger-than-256 value as the 2nd parameter, this value will eventually be sent to biovec_slab() as parameter 'nr_vecs' in following code path, bio_alloc_bioset() ==> bvec_alloc() ==> biovec_slab() Because parameter 'nr_vecs' is larger-than-256 value, the panic by BUG() in code block 3 is triggered inside biovec_slab(). From the above analysis, we know that the 4th parameter 'sector' sent into cached_dev_cache_miss() may cause overflow in code block 5 and 6, and finally cause kernel panic in code block 2 and 3. And if result of bio_sectors(bio) + reada exceeds valid bvecs number, it may also trigger kernel panic in code block 3 from code block 6. Now the almost-useless readahead size for cache missing request back to backing device is removed, this patch can fix the oversized issue with more simpler method. - add a local variable size_limit, set it by the minimum value from the max bkey size and max bio bvecs number. - set s->insert_bio_sectors by the minimum value from size_limit, sectors, and the sectors size of bio. - replace sectors by s->insert_bio_sectors to do bio_next_split. By the above method with size_limit, s->insert_bio_sectors will never result oversized replace_key size or bio bvecs number. And split bio 'miss' from bio_next_split() will always match the size of 'cache_bio', that is the current maximum bio size we can sent to backing device for fetching the cache missing data. Current problmatic code can be partially found since Linux v3.13-rc1, therefore all maintained stable kernels should try to apply this fix. Reported-by: Alexander Ullrich <ealex1979(a)gmail.com> Reported-by: Diego Ercolani <diego.ercolani(a)gmail.com> Reported-by: Jan Szubiak <jan.szubiak(a)linuxpolska.pl> Reported-by: Marco Rebhan <me(a)dblsaiko.net> Reported-by: Matthias Ferdinand <bcache(a)mfedv.net> Reported-by: Victor Westerhuis <victor(a)westerhu.is> Reported-by: Vojtech Pavlik <vojtech(a)suse.cz> Reported-and-tested-by: Rolf Fokkens <rolf(a)rolffokkens.nl> Reported-and-tested-by: Thorsten Knabe <linux(a)thorsten-knabe.de> Signed-off-by: Coly Li <colyli(a)suse.de> Cc: stable(a)vger.kernel.org Cc: Christoph Hellwig <hch(a)lst.de> Cc: Kent Overstreet <kent.overstreet(a)gmail.com> Cc: Nix <nix(a)esperi.org.uk> Cc: Takashi Iwai <tiwai(a)suse.com> Link: https://lore.kernel.org/r/20210607125052.21277-3-colyli@suse.de Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: drivers/md/bcache/request.c [Fix context conflict and use BIO_MAX_PAGES because BIO_MAX_VECS is not defined but with the same value] Signed-off-by: Xiang Yang <xiangyang3(a)huawei.com> --- drivers/md/bcache/request.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c index 5933ba353409..cd1184537af6 100644 --- a/drivers/md/bcache/request.c +++ b/drivers/md/bcache/request.c @@ -917,6 +917,7 @@ static int cached_dev_cache_miss(struct btree *b, struct search *s, unsigned int reada = 0; struct cached_dev *dc = container_of(s->d, struct cached_dev, disk); struct bio *miss, *cache_bio; + unsigned int size_limit; s->cache_missed = 1; @@ -935,7 +936,10 @@ static int cached_dev_cache_miss(struct btree *b, struct search *s, reada = min_t(sector_t, dc->readahead >> 9, get_capacity(bio->bi_disk) - bio_end_sector(bio)); - s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); + /* Limitation for valid replace key size and cache_bio bvecs number */ + size_limit = min_t(unsigned int, BIO_MAX_PAGES * PAGE_SECTORS, + (1 << KEY_SIZE_BITS) - 1); + s->insert_bio_sectors = min3(size_limit, sectors, bio_sectors(bio)); s->iop.replace_key = KEY(s->iop.inode, bio->bi_iter.bi_sector + s->insert_bio_sectors, @@ -947,7 +951,8 @@ static int cached_dev_cache_miss(struct btree *b, struct search *s, s->iop.replace = true; - miss = bio_next_split(bio, sectors, GFP_NOIO, &s->d->bio_split); + miss = bio_next_split(bio, s->insert_bio_sectors, GFP_NOIO, + &s->d->bio_split); /* btree_search_recurse()'s btree iterator is no good anymore */ ret = miss == bio ? MAP_DONE : -EINTR; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()
by Zheng Yejian 04 Jun '24

04 Jun '24

From: Zhou Qingyang <zhou1615(a)umn.edu> stable inclusion from stable-v4.19.220 commit 57af54a56024435d83e44c78449513b414eb6edf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9S240 CVE: CVE-2021-47542 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e2dabc4f7e7b60299c20a36d6a7b24ed9bf8e572 upstream. In qlcnic_83xx_add_rings(), the indirect function of ahw->hw_ops->alloc_mbx_args will be called to allocate memory for cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(), which could lead to a NULL pointer dereference on failure of the indirect function like qlcnic_83xx_alloc_mbx_args(). Fix this bug by adding a check of alloc_mbx_args(), this patch imitates the logic of mbx_cmd()'s failure handling. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_QLCNIC=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 7f9664525f9c ("qlcnic: 83xx memory map and HW access routine") Signed-off-by: Zhou Qingyang <zhou1615(a)umn.edu> Link: https://lore.kernel.org/r/20211130110848.109026-1-zhou1615@umn.edu Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com> --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c index a79d84f99102..40df02590f8a 100644 --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c @@ -1079,8 +1079,14 @@ static int qlcnic_83xx_add_rings(struct qlcnic_adapter *adapter) sds_mbx_size = sizeof(struct qlcnic_sds_mbx); context_id = recv_ctx->context_id; num_sds = adapter->drv_sds_rings - QLCNIC_MAX_SDS_RINGS; - ahw->hw_ops->alloc_mbx_args(&cmd, adapter, - QLCNIC_CMD_ADD_RCV_RINGS); + err = ahw->hw_ops->alloc_mbx_args(&cmd, adapter, + QLCNIC_CMD_ADD_RCV_RINGS); + if (err) { + dev_err(&adapter->pdev->dev, + "Failed to alloc mbx args %d\n", err); + return err; + } + cmd.req.arg[1] = 0 | (num_sds << 8) | (context_id << 16); /* set up status rings, mbx 2-81 */ -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] can: peak_pci: peak_pci_remove(): fix UAF
by felix 04 Jun '24

04 Jun '24

From: Zheyu Ma <zheyuma97(a)gmail.com> stable inclusion from stable-v4.19.214 commit adbda14730aacce41c0d3596415aa39ad63eafd9 bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RBFB CVE: CVE-2021-47456 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 949fe9b35570361bc6ee2652f89a0561b26eec98 upstream. When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF. Fix this by releasing 'dev' later. The following log reveals it: [ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0x3b0 [ 35.966420 ] kasan_report+0x172/0x1c0 [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170 [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.968752 ] pci_device_remove+0xa9/0x250 Fixes: e6d9c80b7ca1 ("can: peak_pci: add support of some new PEAK-System PCI cards") Link: https://lore.kernel.org/all/1634192913-15639-1-git-send-email-zheyuma97@gma… Cc: stable(a)vger.kernel.org Signed-off-by: Zheyu Ma <zheyuma97(a)gmail.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Felix Fu <fuzhen5(a)huawei.com> --- drivers/net/can/sja1000/peak_pci.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/net/can/sja1000/peak_pci.c b/drivers/net/can/sja1000/peak_pci.c index a97b81d1d0da..e989841b411f 100644 --- a/drivers/net/can/sja1000/peak_pci.c +++ b/drivers/net/can/sja1000/peak_pci.c @@ -739,16 +739,15 @@ static void peak_pci_remove(struct pci_dev *pdev) struct net_device *prev_dev = chan->prev_dev; dev_info(&pdev->dev, "removing device %s\n", dev->name); + /* do that only for first channel */ + if (!prev_dev && chan->pciec_card) + peak_pciec_remove(chan->pciec_card); unregister_sja1000dev(dev); free_sja1000dev(dev); dev = prev_dev; - if (!dev) { - /* do that only for first channel */ - if (chan->pciec_card) - peak_pciec_remove(chan->pciec_card); + if (!dev) break; - } priv = netdev_priv(dev); chan = priv->priv; } -- 2.34.1

2 1