- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] tipc: fix a possible memleak in tipc_buf_append
by Zhengchao Shao 04 Jun '24

04 Jun '24

From: Xin Long <lucien.xin(a)gmail.com> stable inclusion from stable-v5.10.217 commit adbce6d20da6254c86425a8d4359b221b5ccbccd category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9US4T CVE: CVE-2024-36954 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 97bf6f81b29a8efaf5d0983251a7450e5794370d ] __skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path. Fixes: b7df21cf1b79 ("tipc: skb_linearize the head skb when reassembling msgs") Reported-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Tung Nguyen <tung.q.nguyen(a)dektech.com.au> Link: https://lore.kernel.org/r/90710748c29a1521efac4f75ea01b3b7e61414cf.17144858… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/tipc/msg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tipc/msg.c b/net/tipc/msg.c index 91dcf648d32b..b2b102d6f581 100644 --- a/net/tipc/msg.c +++ b/net/tipc/msg.c @@ -148,9 +148,9 @@ int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff **buf) if (fragid == FIRST_FRAGMENT) { if (unlikely(head)) goto err; - *buf = NULL; if (skb_has_frag_list(frag) && __skb_linearize(frag)) goto err; + *buf = NULL; frag = skb_unshare(frag, GFP_ATOMIC); if (unlikely(!frag)) goto err; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] batman-adv: Avoid infinite loop trying to resize local TT
by Guo Mengqi 04 Jun '24

04 Jun '24

From: Sven Eckelmann <sven(a)narfation.org> stable inclusion from stable-v4.19.313 commit 04720ea2e6c64459a90ca28570ea78335eccd924 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9QRL7 CVE: CVE-2024-35982 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit b1f532a3b1e6d2e5559c7ace49322922637a28aa upstream. If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes. While this should be handled proactively when: * interface with too low MTU is added * VLAN is added * non-purgeable local mac is added * MTU of an attached interface is reduced * fragmentation setting gets disabled (which most likely requires dropping attached interfaces) not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present. Cc: stable(a)vger.kernel.org Fixes: a19d3d85e1b8 ("batman-adv: limit local translation table max size") Reported-by: syzbot+a6a4b5bb3da165594cff(a)syzkaller.appspotmail.com Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- net/batman-adv/translation-table.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c index 9fa5389ea244..ef19d0ef3527 100644 --- a/net/batman-adv/translation-table.c +++ b/net/batman-adv/translation-table.c @@ -4197,7 +4197,7 @@ void batadv_tt_local_resize_to_mtu(struct net_device *soft_iface) spin_lock_bh(&bat_priv->tt.commit_lock); - while (true) { + while (timeout) { table_size = batadv_tt_local_table_transmit_size(bat_priv); if (packet_size_max >= table_size) break; -- 2.17.1

2 1

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

04 Jun '24

fix CVE-2024-36906 Boy.Wu (1): ARM: 9381/1: kasan: clear stale stack poison arch/arm/kernel/sleep.S | 4 ++++ 1 file changed, 4 insertions(+) -- 2.34.1

2 2

[PATCH OLK-5.10] ARM: 9381/1: kasan: clear stale stack poison
by Hongbo Li 04 Jun '24

04 Jun '24

From: "Boy.Wu" <boy.wu(a)mediatek.com> mainline inclusion from mainline-v6.9 commit c4238686f9093b98bd6245a348bcf059cdce23af category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UOQ7 CVE: CVE-2024-36906 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ================================================================== We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle. This patch refer to arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK") Signed-off-by: Boy Wu <boy.wu(a)mediatek.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Acked-by: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Fixes: 5615f69bc209 ("ARM: 9016/2: Initialize the mapping of KASan shadow memory") Signed-off-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Conflicts: arch/arm/kernel/sleep.S [lhb: adjust context] Signed-off-by: Hongbo Li <lihongbo22(a)huawei.com> --- arch/arm/kernel/sleep.S | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S index 7e64648654ae..33e0fa92efdd 100644 --- a/arch/arm/kernel/sleep.S +++ b/arch/arm/kernel/sleep.S @@ -113,6 +113,10 @@ ENDPROC(cpu_resume_mmu) .popsection cpu_resume_after_mmu: bl cpu_init @ restore the und/abt/irq banked regs +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK) + mov r0, sp + bl kasan_unpoison_task_stack_below +#endif mov r0, #0 @ return zero on success ldmfd sp!, {r4 - r11, pc} ENDPROC(cpu_resume_after_mmu) -- 2.34.1

2 1

[PATCH OLK-5.10 v2 0/7] arm64 mpam fix patch
by Yu Liao 04 Jun '24

04 Jun '24

arm64 mpam fix patch Yu Liao (7): mpam/resctrl: Fix a deadlock due to inaccurate reference mpam/resctrl: Clean up unused function parameter in mkdir path mpam/resctrl: Clean up resctrl_group_rmdir_[ctrl/mon]() mpam/resctrl: Fix use-after-free due to inaccurate refcount of rdtgroup arm64/mpam: change allocation mode from GFP_KERNEL to GFP_NOWAIT arm64/mpam: Fix wrong seconds to jiffies conversion arm64/mpam: Fix softlockup when reading mondata arch/arm64/kernel/mpam/mpam_ctrlmon.c | 3 ++ arch/arm64/kernel/mpam/mpam_resctrl.c | 6 +-- fs/resctrlfs.c | 57 ++++++++++----------------- 3 files changed, 27 insertions(+), 39 deletions(-) -- 2.33.0

2 8

[PATCH openEuler-1.0-LTS 0/1] CVE-2021-47358
by Wupeng Ma 04 Jun '24

04 Jun '24

From: Ma Wupeng <mawupeng1(a)huawei.com> Backport the following patch to fix cve CVE-2021-47358. 92dc0b1f46e1 staging: greybus: uart: fix tty use after free Johan Hovold (1): staging: greybus: uart: fix tty use after free drivers/staging/greybus/uart.c | 62 ++++++++++++++++++---------------- 1 file changed, 32 insertions(+), 30 deletions(-) -- 2.25.1

2 2

[OLK-5.10] ARM: 9381/1: kasan: clear stale stack poison
by Hongbo Li 04 Jun '24

04 Jun '24

From: "Boy.Wu" <boy.wu(a)mediatek.com> mainline inclusion from mainline-v6.9 commit c4238686f9093b98bd6245a348bcf059cdce23af category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9UOQ7 CVE: CVE-2024-36906 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ================================================================== We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle. This patch refer to arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK") Signed-off-by: Boy Wu <boy.wu(a)mediatek.com> Reviewed-by: Mark Rutland <mark.rutland(a)arm.com> Acked-by: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Fixes: 5615f69bc209 ("ARM: 9016/2: Initialize the mapping of KASan shadow memory") Signed-off-by: Russell King (Oracle) <rmk+kernel(a)armlinux.org.uk> Conflicts: arch/arm/kernel/sleep.S [lhb: adjust context] Signed-off-by: Hongbo Li <lihongbo22(a)huawei.com> --- arch/arm/kernel/sleep.S | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S index 7e64648654ae..33e0fa92efdd 100644 --- a/arch/arm/kernel/sleep.S +++ b/arch/arm/kernel/sleep.S @@ -113,6 +113,10 @@ ENDPROC(cpu_resume_mmu) .popsection cpu_resume_after_mmu: bl cpu_init @ restore the und/abt/irq banked regs +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK) + mov r0, sp + bl kasan_unpoison_task_stack_below +#endif mov r0, #0 @ return zero on success ldmfd sp!, {r4 - r11, pc} ENDPROC(cpu_resume_after_mmu) -- 2.34.1

1 0

[PATCH openEuler-1.0-LTS] 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] 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..87d51389a72a 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_VECS * 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 OLK-5.10] octeontx2-af: Fix possible null pointer dereference.
by Guo Mengqi 04 Jun '24

04 Jun '24

From: Rakesh Babu Saladi <rsaladi2(a)marvell.com> mainline inclusion from mainline-v5.15 commit c2d4c543f74c90f883e8ec62a31973ae8807d354 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9RDAK CVE: CVE-2021-47484 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- This patch fixes possible null pointer dereference in file "rvu_debugfs.c" Fixes: 8756828a8148 ("octeontx2-af: Add NPA aura and pool contexts to debugfs") Signed-off-by: Rakesh Babu Saladi <rsaladi2(a)marvell.com> Signed-off-by: Subbaraya Sundeep <sbhatta(a)marvell.com> Signed-off-by: Sunil Goutham <sgoutham(a)marvell.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Conflicts: drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c [File introduced in 5.11] Signed-off-by: Guo Mengqi <guomengqi3(a)huawei.com> --- drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c index 5205796859f6..24ebcf3d0c9c 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c @@ -438,7 +438,7 @@ static ssize_t rvu_dbg_qsize_write(struct file *filp, if (cmd_buf) ret = -EINVAL; - if (!strncmp(subtoken, "help", 4) || ret < 0) { + if (ret < 0 || !strncmp(subtoken, "help", 4)) { dev_info(rvu->dev, "Use echo <%s-lf > qsize\n", blk_string); goto qsize_write_done; } -- 2.17.1

2 1

[PATCH V2 OLK-5.10] iommu/iova: move depot up to avoid cache conflict
by Zhang Zekun 04 Jun '24

04 Jun '24

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9TIC6 ------------------------------------------ The first four params in struct iova_rcache will share the same cache line. The depot related parameter which will be upated each time the depot has been changed, and it should not influence the field "cpu_rcache". Moving the delayed_work up to avoid cache false-sharing, because it has 192 Bytes, which should be enough for sperating a cache line. The optimization can be reflected by perf top: Before: 31.13% [kernel] [k] queue_iova 23.02% [kernel] [k] __iova_rcache_get 7.78% [kernel] [k] __arm_lpae_unmap 6.18% [kernel] [k] arm_lpae_map 3.91% [kernel] [k] sch_direct_xmit 3.19% [kernel] [k] __arm_lpae_map 1.50% [kernel] [k] __dev_queue_xmit After: 15.88% [kernel] [k] __arm_lpae_unmap 11.33% [kernel] [k] arm_lpae_map 7.98% [kernel] [k] sch_direct_xmit 6.71% [kernel] [k] __arm_lpae_map 5.35% [kernel] [k] queue_iova 3.09% [kernel] [k] __dev_queue_xmit 2.83% [kernel] [k] ip_finish_output2 Fixes: 876b598ef137 ("iommu/iova: Make the rcache depot scale better") Signed-off-by: Zhang Zekun <zhangzekun11(a)huawei.com> --- v2: - add fix tag. include/linux/iova.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/iova.h b/include/linux/iova.h index ccc59e4b6c54..32996e73ce19 100644 --- a/include/linux/iova.h +++ b/include/linux/iova.h @@ -31,9 +31,9 @@ struct iova_rcache { spinlock_t lock; unsigned int depot_size; struct iova_magazine *depot; + struct delayed_work work; struct iova_cpu_rcache __percpu *cpu_rcaches; struct iova_domain *iovad; - struct delayed_work work; KABI_RESERVE(1) KABI_RESERVE(2) }; -- 2.17.1

2 1