- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] bonding: alb: fix UAF in rlb_arp_recv during bond up/down
by superdcc97＠163.com 03 Jun '26

03 Jun '26

From: Hangbin Liu <liuhangbin(a)gmail.com> mainline inclusion from mainline-v7.0-rc1 commit e6834a4c474697df23ab9948fd3577b26bf48656 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15209 CVE: CVE-2026-45970 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] <IRQ> [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ> The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize(). Reported-by: Liang Li <liali(a)redhat.com> Fixes: 3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()") Reviewed-by: Nikolay Aleksandrov <nikolay(a)nvidia.com> Acked-by: Jay Vosburgh <jv(a)jvosburgh.net> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Link: https://patch.msgid.link/20260218060919.101574-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/bonding/bond_main.c [commit ce7a381697cb ("net: bonding: add broadcast_neighbor option for 802.3ad") is not backported, so the target kernel has a simplified bond_close() without the BOND_MODE_8023AD block, causing patch context mismatch. Applied the core fix (WRITE_ONCE + synchronize_net + removing the old bond->recv_probe = NULL) while keeping the target's existing code structure.] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/bonding/bond_main.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 56c16b171e35..30a9bf8804ac 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -3475,9 +3475,13 @@ static int bond_close(struct net_device *bond_dev) bond_work_cancel_all(bond); bond->send_peer_notif = 0; + WRITE_ONCE(bond->recv_probe, NULL); + + /* Wait for any in-flight RX handlers */ + synchronize_net(); + if (bond_is_lb(bond)) bond_alb_deinitialize(bond); - bond->recv_probe = NULL; return 0; } -- 2.43.0

2 1

[PATCH] bonding: alb: fix UAF in rlb_arp_recv during bond up/down
by superdcc97＠163.com 03 Jun '26

03 Jun '26

From: Hangbin Liu <liuhangbin(a)gmail.com> mainline inclusion from mainline-v7.0-rc1 commit e6834a4c474697df23ab9948fd3577b26bf48656 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15209 CVE: CVE-2026-45970 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The ALB RX path may access rx_hashtbl concurrently with bond teardown. During rapid bond up/down cycles, rlb_deinitialize() frees rx_hashtbl while RX handlers are still running, leading to a null pointer dereference detected by KASAN. However, the root cause is that rlb_arp_recv() can still be accessed after setting recv_probe to NULL, which is actually a use-after-free (UAF) issue. That is the reason for using the referenced commit in the Fixes tag. [ 214.174138] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001d: 0000 [#1] SMP KASAN PTI [ 214.186478] KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef] [ 214.194933] CPU: 30 UID: 0 PID: 2375 Comm: ping Kdump: loaded Not tainted 6.19.0-rc8+ #2 PREEMPT(voluntary) [ 214.205907] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.14.0 01/14/2022 [ 214.214357] RIP: 0010:rlb_arp_recv+0x505/0xab0 [bonding] [ 214.220320] Code: 0f 85 2b 05 00 00 48 b8 00 00 00 00 00 fc ff df 40 0f b6 ed 48 c1 e5 06 49 03 ad 78 01 00 00 48 8d 7d 28 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 12 05 00 00 80 7d 28 00 0f 84 8c 00 [ 214.241280] RSP: 0018:ffffc900073d8870 EFLAGS: 00010206 [ 214.247116] RAX: dffffc0000000000 RBX: ffff888168556822 RCX: ffff88816855681e [ 214.255082] RDX: 000000000000001d RSI: dffffc0000000000 RDI: 00000000000000e8 [ 214.263048] RBP: 00000000000000c0 R08: 0000000000000002 R09: ffffed11192021c8 [ 214.271013] R10: ffff8888c9010e43 R11: 0000000000000001 R12: 1ffff92000e7b119 [ 214.278978] R13: ffff8888c9010e00 R14: ffff888168556822 R15: ffff888168556810 [ 214.286943] FS: 00007f85d2d9cb80(0000) GS:ffff88886ccb3000(0000) knlGS:0000000000000000 [ 214.295966] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 214.302380] CR2: 00007f0d047b5e34 CR3: 00000008a1c2e002 CR4: 00000000001726f0 [ 214.310347] Call Trace: [ 214.313070] <IRQ> [ 214.315318] ? __pfx_rlb_arp_recv+0x10/0x10 [bonding] [ 214.320975] bond_handle_frame+0x166/0xb60 [bonding] [ 214.326537] ? __pfx_bond_handle_frame+0x10/0x10 [bonding] [ 214.332680] __netif_receive_skb_core.constprop.0+0x576/0x2710 [ 214.339199] ? __pfx_arp_process+0x10/0x10 [ 214.343775] ? sched_balance_find_src_group+0x98/0x630 [ 214.349513] ? __pfx___netif_receive_skb_core.constprop.0+0x10/0x10 [ 214.356513] ? arp_rcv+0x307/0x690 [ 214.360311] ? __pfx_arp_rcv+0x10/0x10 [ 214.364499] ? __lock_acquire+0x58c/0xbd0 [ 214.368975] __netif_receive_skb_one_core+0xae/0x1b0 [ 214.374518] ? __pfx___netif_receive_skb_one_core+0x10/0x10 [ 214.380743] ? lock_acquire+0x10b/0x140 [ 214.385026] process_backlog+0x3f1/0x13a0 [ 214.389502] ? process_backlog+0x3aa/0x13a0 [ 214.394174] __napi_poll.constprop.0+0x9f/0x370 [ 214.399233] net_rx_action+0x8c1/0xe60 [ 214.403423] ? __pfx_net_rx_action+0x10/0x10 [ 214.408193] ? lock_acquire.part.0+0xbd/0x260 [ 214.413058] ? sched_clock_cpu+0x6c/0x540 [ 214.417540] ? mark_held_locks+0x40/0x70 [ 214.421920] handle_softirqs+0x1fd/0x860 [ 214.426302] ? __pfx_handle_softirqs+0x10/0x10 [ 214.431264] ? __neigh_event_send+0x2d6/0xf50 [ 214.436131] do_softirq+0xb1/0xf0 [ 214.439830] </IRQ> The issue is reproducible by repeatedly running ip link set bond0 up/down while receiving ARP messages, where rlb_arp_recv() can race with rlb_deinitialize() and dereference a freed rx_hashtbl entry. Fix this by setting recv_probe to NULL and then calling synchronize_net() to wait for any concurrent RX processing to finish. This ensures that no RX handler can access rx_hashtbl after it is freed in bond_alb_deinitialize(). Reported-by: Liang Li <liali(a)redhat.com> Fixes: 3aba891dde38 ("bonding: move processing of recv handlers into handle_frame()") Reviewed-by: Nikolay Aleksandrov <nikolay(a)nvidia.com> Acked-by: Jay Vosburgh <jv(a)jvosburgh.net> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Link: https://patch.msgid.link/20260218060919.101574-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/bonding/bond_main.c [commit ce7a381697cb ("net: bonding: add broadcast_neighbor option for 802.3ad") is not backported, so the target kernel has a simplified bond_close() without the BOND_MODE_8023AD block, causing patch context mismatch. Applied the core fix (WRITE_ONCE + synchronize_net + removing the old bond->recv_probe = NULL) while keeping the target's existing code structure.] Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- drivers/net/bonding/bond_main.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c index 56c16b171e35..30a9bf8804ac 100644 --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -3475,9 +3475,13 @@ static int bond_close(struct net_device *bond_dev) bond_work_cancel_all(bond); bond->send_peer_notif = 0; + WRITE_ONCE(bond->recv_probe, NULL); + + /* Wait for any in-flight RX handlers */ + synchronize_net(); + if (bond_is_lb(bond)) bond_alb_deinitialize(bond); - bond->recv_probe = NULL; return 0; } -- 2.43.0

1 0

[PATCH OLK-5.10] KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2
by Zhang Kunbo 03 Jun '26

03 Jun '26

From: Yosry Ahmed <yosry(a)kernel.org> stable inclusion from stable-v6.6.140 commit 1709418535a8df95532999d61b03d59975280258 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15238 CVE: CVE-2026-45987 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 03bee264f8ebfd39e0254c98e112d033a7aa9055 upstream. After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable(a)vger.kernel.org Signed-off-by: Yosry Ahmed <yosry(a)kernel.org> Link: https://patch.msgid.link/20260225005950.3739782-3-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kvm/svm/nested.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c index 382ff1b18161..6dcd9b4cae29 100644 --- a/arch/x86/kvm/svm/nested.c +++ b/arch/x86/kvm/svm/nested.c @@ -307,6 +307,7 @@ void sync_nested_vmcb_control(struct vcpu_svm *svm) u32 mask; svm->nested.ctl.event_inj = svm->vmcb->control.event_inj; svm->nested.ctl.event_inj_err = svm->vmcb->control.event_inj_err; + svm->nested.ctl.int_state = svm->vmcb->control.int_state; /* Only a few fields of int_ctl are written by the processor. */ mask = V_IRQ_MASK | V_TPR_MASK; -- 2.34.1

2 1

[PATCH OLK-6.6 1/2] AppArmor: Allow apparmor to handle unaligned dfa tables
by Gu Bowen 03 Jun '26

03 Jun '26

From: Helge Deller <deller(a)kernel.org> mainline inclusion from mainline-v7.0-rc1 commit 64802f731214a51dfe3c6c27636b3ddafd003eb0 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/15143 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following [ 73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [ 74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [ 74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [ 74.536543] Call Trace: [ 74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [ 74.633757] [<0000000000476438>] __warn+0xd8/0x100 [ 74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [ 74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [ 74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [ 74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [ 74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [ 75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [ 75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [ 75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [ 75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [ 75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [ 75.406932] [<0000000000767174>] sys_write+0x14/0x40 [ 75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [ 75.548802] ---[ end trace 0000000000000000 ]--- [ 75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [ 75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720 Work around it by using the get_unaligned_xx() helpers. Fixes: e6e8bf418850d ("apparmor: fix restricted endian type warnings for dfa unpack") Reported-by: John Paul Adrian Glaubitz <glaubitz(a)physik.fu-berlin.de> Closes: https://github.com/sparclinux/issues/issues/30 Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: John Johansen <john.johansen(a)canonical.com> Conflicts: security/apparmor/match.c [Due to commit 5f60d5f6bbc1 ("move asm/unaligned.h to linux/unaligned.h") not merge.] Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- security/apparmor/match.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/security/apparmor/match.c b/security/apparmor/match.c index ed2ed6e40849..063f0b053320 100644 --- a/security/apparmor/match.c +++ b/security/apparmor/match.c @@ -15,6 +15,7 @@ #include <linux/vmalloc.h> #include <linux/err.h> #include <linux/kref.h> +#include <asm/unaligned.h> #include "include/lib.h" #include "include/match.h" @@ -86,11 +87,11 @@ static struct table_header *unpack_table(char *blob, size_t bsize) /* loaded td_id's start at 1, subtract 1 now to avoid doing * it every time we use td_id as an index */ - th.td_id = be16_to_cpu(*(__be16 *) (blob)) - 1; + th.td_id = get_unaligned_be16(blob) - 1; if (th.td_id > YYTD_ID_MAX) goto out; - th.td_flags = be16_to_cpu(*(__be16 *) (blob + 2)); - th.td_lolen = be32_to_cpu(*(__be32 *) (blob + 8)); + th.td_flags = get_unaligned_be16(blob + 2); + th.td_lolen = get_unaligned_be32(blob + 8); blob += sizeof(struct table_header); if (!(th.td_flags == YYTD_DATA16 || th.td_flags == YYTD_DATA32 || @@ -337,14 +338,14 @@ struct aa_dfa *aa_dfa_unpack(void *blob, size_t size, int flags) if (size < sizeof(struct table_set_header)) goto fail; - if (ntohl(*(__be32 *) data) != YYTH_MAGIC) + if (get_unaligned_be32(data) != YYTH_MAGIC) goto fail; - hsize = ntohl(*(__be32 *) (data + 4)); + hsize = get_unaligned_be32(data + 4); if (size < hsize) goto fail; - dfa->flags = ntohs(*(__be16 *) (data + 12)); + dfa->flags = get_unaligned_be16(data + 12); if (dfa->flags & ~(YYTH_FLAGS)) goto fail; @@ -353,7 +354,7 @@ struct aa_dfa *aa_dfa_unpack(void *blob, size_t size, int flags) * if (dfa->flags & YYTH_FLAGS_OOB_TRANS) { * if (hsize < 16 + 4) * goto fail; - * dfa->max_oob = ntol(*(__be32 *) (data + 16)); + * dfa->max_oob = get_unaligned_be32(data + 16); * if (dfa->max <= MAX_OOB_SUPPORTED) { * pr_err("AppArmor DFA OOB greater than supported\n"); * goto fail; -- 2.43.0

2 2

[PATCH OLK-6.6 0/4] hungtask fix patch and mainline backport
by Chen Jinghuang 03 Jun '26

03 Jun '26

*** BLURB HERE *** Chen Jinghuang (1): sched: Fix kabi broken of struct sched_entity Peter Zijlstra (2): sched/fair: Fix lag clamp sched/fair: Revert 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag") Zhan Xusheng (1): sched/fair: Fix math notation errors in avg_vruntime comment include/linux/sched.h | 2 +- kernel/sched/fair.c | 188 +++++++++++++++++++++++++++++++++++------- 2 files changed, 161 insertions(+), 29 deletions(-) -- 2.34.1

2 5

[PATCH OLK-5.10 0/3] CVEs
by Liu Kai 03 Jun '26

03 Jun '26

CVEs Michael Bommarito (1): RDMA/rxe: Reject unknown opcodes before ICRC processing Shuvam Pandey (1): Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hkbinbin (1): RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv drivers/infiniband/sw/rxe/rxe_recv.c | 14 +++++++++++++- net/bluetooth/hci_event.c | 18 ++++++++++++++---- 2 files changed, 27 insertions(+), 5 deletions(-) -- 2.34.1

2 4

[PATCH openEuler-1.0-LTS 0/3] *** revert CVE-2026-31527 ***
by Lin Ruifeng 03 Jun '26

03 Jun '26

*** revert CVE-2026-31527 *** Lin Ruifeng (3): Revert "driver/core: Fix kabi broken of platform_device/device/bus_type" Revert "driver core: platform: use generic driver_override infrastructure" Revert "driver core: generalize driver_override in struct device" drivers/base/bus.c | 49 +-------------------- drivers/base/core.c | 3 -- drivers/base/dd.c | 61 --------------------------- drivers/base/platform.c | 57 ++++++++++++++++++++++--- drivers/slimbus/qcom-ngd-ctrl.c | 12 +----- include/linux/device.h | 75 --------------------------------- include/linux/platform_device.h | 7 +-- 7 files changed, 55 insertions(+), 209 deletions(-) -- 2.43.0

2 4

[PATCH OLK-6.6] xfs: fix possible bugon in xfs_trans_unreserve_and_mod_sb()
by Long Li 03 Jun '26

03 Jun '26

From: Ye Bin <yebin10(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9228 CVE: NA -------------------------------- Recently, I encountered a problem where a BUG was triggered in the write-back process. The detailed problem information is as follows: xfs_bmap_extents_to_btree: ip=0xffff888148ecad00 wasdel=0 sde: writeback error on inode 68, offset 61440, sector 1400 XFS (sde): Corruption of in-memory data (0x8) detected at xfs_trans_mod_sb+0xaa6/0xc60 (fs/xfs/xfs_trans.c:351). Shutting. XFS (sde): Please unmount the filesystem and rectify the problem(s) XFS: Assertion failed: tp->t_blk_res || tp->t_fdblocks_delta >= 0, file: fs/xfs/xfs_trans.c, line: 610 ------------[ cut here ]------------ kernel BUG at fs/xfs/xfs_message.c:102! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 5 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 7.0.0-rc6-next-20260402-00028-g56f243e5f8ea-dirty #360 P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: writeback wb_workfn (flush-8:64) RIP: 0010:assfail+0x9f/0xb0 Code: fe 84 db 75 20 e8 41 2e 33 fe 0f 0b 5b 5d 41 5c 41 5d e9 94 34 a5 06 48 c7 c7 58 ae 2b 8d e8 f8 72 a0 RSP: 0018:ffffc900000dedd0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff838c91b6 RDX: ffff88810425d880 RSI: ffffffff838c91df RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10e3b14901 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8a956520 R13: 0000000000000262 R14: 0000000000000000 R15: ffffffffffffffff FS: 0000000000000000(0000) GS:ffff88878bdc5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fccb3c788f0 CR3: 000000000c98a000 CR4: 00000000000006f0 Call Trace: <TASK> xfs_trans_unreserve_and_mod_sb+0xb86/0xd00 __xfs_trans_commit+0x38b/0xe00 xfs_trans_commit+0xeb/0x1a0 xfs_bmapi_convert_one_delalloc+0xba9/0x12d0 xfs_bmapi_convert_delalloc+0x101/0x350 xfs_writeback_range+0x76c/0x12d0 iomap_writeback_folio+0x9ed/0x2100 iomap_writepages+0x13c/0x2a0 xfs_vm_writepages+0x278/0x330 do_writepages+0x247/0x5c0 __writeback_single_inode+0x123/0x1370 writeback_sb_inodes+0x71e/0x1b90 __writeback_inodes_wb+0xc3/0x280 wb_writeback+0x730/0xb80 wb_workfn+0x8b0/0xbc0 process_one_work+0xa08/0x1d00 worker_thread+0x698/0xeb0 kthread+0x408/0x540 ret_from_fork+0xa4d/0xdd0 ret_from_fork_asm+0x1a/0x30 </TASK> After analyzing the above issues, the possible triggering process is as follows: xfs_bmapi_convert_delalloc xfs_bmapi_convert_one_delalloc xfs_bmapi_allocate xfs_bmap_add_extent_delay_real da_old = startblockval(PREV.br_startblock); // da_old = 5 case BMAP_LEFT_FILLING: ifp->if_nextents++; // 21 + 1 = 22 if (xfs_bmap_needs_btree(bma->ip, whichfork)) // 22 > 21 xfs_bmap_extents_to_btree // convert to btree cur->bc_ino.allocated++; // da_new = 5 - 1 = 4 da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), startblockval(PREV.br_startblock) - (bma->cur ? bma->cur->bc_ino.allocated : 0)) //xfs_bmapi_convert_one_delalloc() return PREV.br_startblock = nullstartblock(da_new); xfs_bmap_del_extent_real case BMAP_LEFT_FILLING | BMAP_RIGHT_FILLING: ifp->if_nextents--; // 22 - 1 = 21 if (xfs_bmap_needs_btree(ip, whichfork)) xfs_bmap_extents_to_btree(); else // convert to extents xfs_bmap_btree_to_extents(); ... // Alternate a few times in the middle. da_old = 4 da_old = 3 da_old = 2 da_old = 1 ... xfs_bmapi_convert_delalloc xfs_bmapi_convert_one_delalloc // Both blocks and rtextents are 0 error = xfs_trans_alloc(mp, &M_RES(mp)->tr_write, 0, 0, XFS_TRANS_RESERVE, &tp); tp = kmem_cache_zalloc(xfs_trans_cache, GFP_KERNEL | __GFP_NOFAIL); error = xfs_trans_reserve(tp, resp, blocks, rtextents); if (blocks > 0) error = xfs_mod_fdblocks(mp, -((int64_t)blocks), rsvd); // The value of blocks is 0, so the value of tp->t_blk_res is 0 tp->t_blk_res += blocks; xfs_bmapi_allocate xfs_bmap_add_extent_delay_real da_old = startblockval(PREV.br_startblock); // da_old = 0 // The current delay extent is just exhausted. case BMAP_LEFT_FILLING | BMAP_RIGHT_FILLING ifp->if_nextents++; // 21 + 1 + 22 if (xfs_bmap_needs_btree(bma->ip, whichfork)) // 22 > 21 // Converted to btree. da_old > 0 is false. error = xfs_bmap_extents_to_btree(bma->tp, bma->ip, &bma->cur, da_old > 0, &tmp_logflags, whichfork); args.wasdel = wasdel; // wasdel is false error = xfs_alloc_vextent_start_ag(&args, XFS_INO_TO_FSB(mp, ip->i_ino)); xfs_alloc_vextent_finish(args, minimum_agno, error, true); xfs_ag_resv_alloc_extent(args->pag, args->resv, args); case XFS_AG_RESV_NONE: field = args->wasdel ? XFS_TRANS_SB_RES_FDBLOCKS : XFS_TRANS_SB_FDBLOCKS; //args->wasdel == false xfs_trans_mod_sb(args->tp, field, -(int64_t)args->len); case XFS_TRANS_SB_FDBLOCKS: if (delta < 0) tp->t_blk_res_used += (uint)-delta; if (tp->t_blk_res_used > tp->t_blk_res) // ***tp->t_blk_res is 0, thus triggering xfs_force_shutdown()*** xfs_force_shutdown(mp, SHUTDOWN_CORRUPT_INCORE); The logic that triggers the issue above was designed by me to facilitate the construction of the problem. Besides the scenario where BTREE and EXTENTS are converted back and forth, there is also the scenario of btree splitting. The core reason for the issue is that in xfs_bmapi_convert_delalloc(), the call to xfs_bmap_worst_indlen() calculates the worst-case number of reserved blocks, which is the number of additional blocks required after a complete conversion of the entire delayed extent. It assumes that the entire conversion process is atomic. However, the current process cannot guarantee such atomicity. In the case of a fragmented filesystem, the most extreme scenario is that every block conversion triggers a full btree split, in which case the reserved blocks are far from sufficient. When this issue is triggered, the filesystem fragmentation in the environment is indeed quite severe. Further analysis of this abnormal model shows that because the reserved blocks are continuously consumed, they may eventually exceed the reserved amount. When the space is nearly exhausted, xfs_bmap_extents_to_btree() may fail to allocate blocks, triggering a warning. This failure to allocate additional blocks can lead to issues with normal block allocation. Since a single delay extent cannot guarantee a one-time completion of the conversion, the 'inlen' of the delay extent should be maintained at the value calculated by xfs_bmap_worst_indlen(). Commit d69bee6a35d3 ("xfs: fix xfs_bmap_add_extent_delay_real for partial conversions") addressed the issue of potentially not reserving enough space in emergency situations. Based on this modification, we can recalculate the worst-case 'inlen' required for the remaining delay extents after the conversion in xfs_bmap_add_extent_delay_real(), instead of using the remaining value. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ye Bin <yebin10(a)huawei.com> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_bmap.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index 9ed22d82c000..3d655c1bef7d 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -1656,8 +1656,7 @@ xfs_bmap_add_extent_delay_real( */ old = LEFT; temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); LEFT.br_blockcount += new->br_blockcount; @@ -1724,9 +1723,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock) - - (bma->cur ? bma->cur->bc_ino.allocated : 0)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_startoff = new_endoff; PREV.br_blockcount = temp; @@ -1763,8 +1760,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_blockcount = temp; PREV.br_startblock = nullstartblock(da_new); @@ -1812,9 +1808,7 @@ xfs_bmap_add_extent_delay_real( } temp = PREV.br_blockcount - new->br_blockcount; - da_new = XFS_FILBLKS_MIN(xfs_bmap_worst_indlen(bma->ip, temp), - startblockval(PREV.br_startblock) - - (bma->cur ? bma->cur->bc_ino.allocated : 0)); + da_new = xfs_bmap_worst_indlen(bma->ip, temp); PREV.br_startblock = nullstartblock(da_new); PREV.br_blockcount = temp; -- 2.52.0

2 1

[PATCH OLK-5.10 0/2] xfs: fix delay extent reserve issue
by Long Li 03 Jun '26

03 Jun '26

This patch set fix delay extent reserve issue. Christoph Hellwig (1): xfs: fix xfs_bmap_add_extent_delay_real for partial conversions Ye Bin (1): xfs: fix possible bugon in xfs_trans_unreserve_and_mod_sb() fs/xfs/libxfs/xfs_bmap.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6] mm/vmscan: fix wrong callback in shrinker_v2_to_v1_scan_objects()
by Qi Xi 03 Jun '26

03 Jun '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/15059 CVE: NA --------------------------- Fixes the incorrect callback invocation that would cause shrinker behavior mismatch when adapting v2 shrinkers to v1 interface. Fixes: 0dabf4e3ac0f ("mm/shrinker: Implementation of register_shrinker() and unregister_shrinker()") Signed-off-by: Qi Xi <xiqi5703(a)163.com> --- mm/vmscan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index cf6b9e6dc8cd..5c81e3e1e2d7 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -7623,9 +7623,9 @@ static unsigned long shrinker_v2_to_v1_scan_objects(struct shrinker_v2 *shk_v2, struct shrink_control *sc) { if (shk_v2->v1) - return shk_v2->v1->count_objects(shk_v2->v1, sc); + return shk_v2->v1->scan_objects(shk_v2->v1, sc); - return SHRINK_EMPTY; + return SHRINK_STOP; } int register_shrinker(struct shrinker *shrinker, const char *fmt, ...) -- 2.53.0

2 1