- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] Bluetooth: Add more enc key size check
by Zheng Qixing 03 Sep '25

03 Sep '25

From: Alex Lu <alex_lu(a)realsil.com.cn> mainline inclusion from mainline-v6.7-rc7 commit 04a342cc49a8522e99c9b3346371c329d841dcd2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICVV02 CVE: CVE-2023-24023 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------ When we are slave role and receives l2cap conn req when encryption has started, we should check the enc key size to avoid KNOB attack or BLUFFS attack. From SIG recommendation, implementations are advised to reject service-level connections on an encrypted baseband link with key strengths below 7 octets. A simple and clear way to achieve this is to place the enc key size check in hci_cc_read_enc_key_size() The btmon log below shows the case that lacks enc key size check. > HCI Event: Connect Request (0x04) plen 10 Address: BB:22:33:44:55:99 (OUI BB-22-33) Class: 0x480104 Major class: Computer (desktop, notebook, PDA, organizers) Minor class: Desktop workstation Capturing (Scanner, Microphone) Telephony (Cordless telephony, Modem, Headset) Link type: ACL (0x01) < HCI Command: Accept Connection Request (0x01|0x0009) plen 7 Address: BB:22:33:44:55:99 (OUI BB-22-33) Role: Peripheral (0x01) > HCI Event: Command Status (0x0f) plen 4 Accept Connection Request (0x01|0x0009) ncmd 2 Status: Success (0x00) > HCI Event: Connect Complete (0x03) plen 11 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Link type: ACL (0x01) Encryption: Disabled (0x00) ... > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Encryption: Enabled with E0 (0x01) < HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2 Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) > HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 2 Status: Success (0x00) Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Key size: 6 // We should check the enc key size ... > ACL Data RX: Handle 1 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 3 len 4 PSM: 25 (0x0019) Source CID: 64 < ACL Data TX: Handle 1 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 3 len 8 Destination CID: 64 Source CID: 64 Result: Connection pending (0x0001) Status: Authorization pending (0x0002) > HCI Event: Number of Completed Packets (0x13) plen 5 Num handles: 1 Handle: 1 Address: BB:22:33:44:55:99 (OUI BB-22-33) Count: 1 #35: len 16 (25 Kb/s) Latency: 5 msec (2-7 msec ~4 msec) < ACL Data TX: Handle 1 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 3 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000) Cc: stable(a)vger.kernel.org Signed-off-by: Alex Lu <alex_lu(a)realsil.com.cn> Signed-off-by: Max Chou <max.chou(a)realtek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Conflicts: net/bluetooth/hci_event.c [Due to not merging commit 278d933e12f1 ("Bluetooth: Normalize HCI_OP_READ_ENC_KEY_SIZE cmdcmplt").] Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- net/bluetooth/hci_event.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 037f923b433b..90e076013bad 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -3053,6 +3053,7 @@ static void read_enc_key_size_complete(struct hci_dev *hdev, u8 status, const struct hci_rp_read_enc_key_size *rp; struct hci_conn *conn; u16 handle; + u8 st; BT_DBG("%s status 0x%02x", hdev->name, status); @@ -3062,6 +3063,7 @@ static void read_enc_key_size_complete(struct hci_dev *hdev, u8 status, } rp = (void *)skb->data; + st = rp->status; handle = le16_to_cpu(rp->handle); hci_dev_lock(hdev); @@ -3074,15 +3076,30 @@ static void read_enc_key_size_complete(struct hci_dev *hdev, u8 status, * secure approach is to then assume the key size is 0 to force a * disconnection. */ - if (rp->status) { + if (st) { bt_dev_err(hdev, "failed to read key size for handle %u", handle); conn->enc_key_size = 0; } else { conn->enc_key_size = rp->key_size; + st = 0; + + if (conn->enc_key_size < hdev->min_enc_key_size) { + /* As slave role, the conn->state has been set to + * BT_CONNECTED and l2cap conn req might not be received + * yet, at this moment the l2cap layer almost does + * nothing with the non-zero status. + * So we also clear encrypt related bits, and then the + * handler of l2cap conn req will get the right secure + * state at a later time. + */ + st = HCI_ERROR_AUTH_FAILURE; + clear_bit(HCI_CONN_ENCRYPT, &conn->flags); + clear_bit(HCI_CONN_AES_CCM, &conn->flags); + } } - hci_encrypt_cfm(conn, 0); + hci_encrypt_cfm(conn, st); unlock: hci_dev_unlock(hdev); -- 2.39.2

2 1

[PATCH] memcg: introduce memcg early oom feature
by zhaoxuedong 03 Sep '25

03 Sep '25

meituan inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/ICTXDJ CVE: NA -------------------------------- Introduce memcg early oom feature to trigger OOM killer earlier; this feature is disabled by default. Signed-off-by: Zhao Xuedong <zhaoxuedong(a)meituan.com> --- mm/Kconfig | 14 ++++++++++ mm/vmscan.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 87 insertions(+) diff --git a/mm/Kconfig b/mm/Kconfig index cc43f5124cb3..89bcb73b6a5b 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -521,6 +521,20 @@ config MEMCG_SWAP_QOS memcg swap control include memory force swapin, swapfile control and swap limit. +config MEMCG_EARLY_OOM + bool "Enable aggressive memcg OOM killing under memory pressure" + depends on MEMCG + depends on X86 || ARM64 + default n + help + MEMCG_EARLY_OOM makes memory cgroups trigger OOM killer earlier + and more aggressively when under memory pressure, rather than + attempting to reclaim very small amounts of file pages through + prolonged reclaim attempts. + + Say "y" if you prefer fast OOM kills over prolonged reclaim + attempts. + config ETMEM_SCAN tristate "module: etmem page scan for etmem support" depends on ETMEM diff --git a/mm/vmscan.c b/mm/vmscan.c index e82d7995b548..622122473f06 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2470,11 +2470,62 @@ static bool inactive_is_low(struct lruvec *lruvec, enum lru_list inactive_lru) return inactive * inactive_ratio < active; } +#ifdef CONFIG_MEMCG_EARLY_OOM +/* Check if swap usage is over the limit for cgroupv1. */ +static bool is_swap_over_limit(struct mem_cgroup *memcg) +{ + unsigned long mem_limit = READ_ONCE(memcg->memory.max); + unsigned long memsw_limit = READ_ONCE(memcg->memsw.max); + + if (memsw_limit <= mem_limit) + return false; + + return (page_counter_read(&memcg->memsw) - + page_counter_read(&memcg->memory)) > + (memsw_limit - mem_limit); +} + +/* + * Check if file cache is too small to reclaim and anonymous pages are reclaimable. + * Returns true if: + * 1. File cache (+ free space) is below the minimum threshold (pages_min), AND + * 2. Anonymous pages are allowed to be deactivated, AND + * 3. Anonymous pages are abundant relative to reclaim priority + */ +static bool memcg_should_skip_file_reclaim(struct mem_cgroup *memcg, + struct scan_control *sc, + struct lruvec *lruvec) +{ + unsigned long file, anon, free; + unsigned long mem_limit, memsw_usage, mem_high; + unsigned long pages_min; + + if (!cgroup_reclaim(sc)) + return false; + + file = lruvec_lru_size(lruvec, LRU_INACTIVE_FILE, sc->reclaim_idx) + + lruvec_lru_size(lruvec, LRU_ACTIVE_FILE, sc->reclaim_idx); + mem_limit = READ_ONCE(memcg->memory.max); + memsw_usage = page_counter_read(&memcg->memsw); + mem_high = READ_ONCE(memcg->memory.high); + anon = lruvec_lru_size(lruvec, LRU_INACTIVE_ANON, sc->reclaim_idx); + free = mem_limit > memsw_usage ? mem_limit - memsw_usage : 0; + pages_min = mem_limit > mem_high ? (mem_limit - mem_high) >> 2 : 0; + + return (file + free <= pages_min) && + !(sc->may_deactivate & DEACTIVATE_ANON) && + (anon >> sc->priority); +} +#endif + enum scan_balance { SCAN_EQUAL, SCAN_FRACT, SCAN_ANON, SCAN_FILE, +#ifdef CONFIG_MEMCG_EARLY_OOM + SCAN_NONE, +#endif }; /* @@ -2498,6 +2549,20 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, unsigned long ap, fp; enum lru_list lru; +#ifdef CONFIG_MEMCG_EARLY_OOM + /* + * if both file and anon pages are deemed non-reclaimable, + * we deliberately stop reclaiming early to trigger OOM killer + * faster. + */ + if (cgroup_reclaim(sc) && + is_swap_over_limit(memcg) && + memcg_should_skip_file_reclaim(memcg, sc, lruvec)) { + scan_balance = SCAN_NONE; + goto out; + } +#endif + if (sc->not_file) { scan_balance = SCAN_ANON; goto out; @@ -2543,7 +2608,12 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, /* * If the system is almost out of file pages, force-scan anon. */ +#ifdef CONFIG_MEMCG_EARLY_OOM + if (sc->file_is_tiny || + memcg_should_skip_file_reclaim(memcg, sc, lruvec)) { +#else if (sc->file_is_tiny) { +#endif scan_balance = SCAN_ANON; goto out; } @@ -2687,6 +2757,9 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, if ((scan_balance == SCAN_FILE) != file) scan = 0; break; + case SCAN_NONE: + scan = 0; + break; default: /* Look ma, no brain */ BUG(); -- 2.33.0

1 0

[PATCH OLK-5.10 0/8] CVE-2025-38502
by Xiaomeng Zhang 03 Sep '25

03 Sep '25

Daniel Borkmann (4): bpf: Add cookie object to bpf maps bpf: Move bpf map owner out of common struct bpf: Move cgroup iterator helpers to bpf.h bpf: Fix oob access in cgroup local storage Leon Hwang (1): bpf: Fix updating attached freplace prog in prog_array map Toke Hoiland-Jorgensen (1): bpf: generalise tail call map compatibility check Toke Høiland-Jørgensen (1): bpf: Resolve fext program type when checking map compatibility Xiaomeng Zhang (1): Fix kabi breakage for bpf_map by using KABI_FILL_HOLE and KABI_EXTEND include/linux/bpf-cgroup.h | 5 -- include/linux/bpf.h | 90 +++++++++++++++++++++++------------- include/linux/bpf_verifier.h | 5 ++ kernel/bpf/arraymap.c | 4 +- kernel/bpf/core.c | 59 ++++++++++++++--------- kernel/bpf/cpumap.c | 16 ++++--- kernel/bpf/devmap.c | 3 +- kernel/bpf/syscall.c | 22 +++++---- kernel/bpf/verifier.c | 5 -- 9 files changed, 126 insertions(+), 83 deletions(-) -- 2.34.1

2 9

[PATCH OLK-6.6] net/mlx5e: Remove skb secpath if xfrm state is not found
by Yao Kai 03 Sep '25

03 Sep '25

From: Jianbo Liu <jianbol(a)nvidia.com> stable inclusion from stable-v6.6.102 commit 314f568b84b01f6eac1e4313ca47f9ade4349443 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICU74X CVE: CVE-2025-38590 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6d19c44b5c6dd72f9a357d0399604ec16a77de3c ] Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup. Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0. Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer. This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 </IRQ> Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload") Signed-off-by: Jianbo Liu <jianbol(a)nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea(a)nvidia.com> Reviewed-by: Yael Chemla <ychemla(a)nvidia.com> Signed-off-by: Tariq Toukan <tariqt(a)nvidia.com> Link: https://patch.msgid.link/1753256672-337784-3-git-send-email-tariqt@nvidia.c… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yao Kai <yaokai34(a)huawei.com> --- drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c index 51a144246ea6..f96e9bbf8fc6 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_rxtx.c @@ -333,6 +333,10 @@ void mlx5e_ipsec_offload_handle_rx_skb(struct net_device *netdev, if (unlikely(!sa_entry)) { rcu_read_unlock(); atomic64_inc(&ipsec->sw_stats.ipsec_rx_drop_sadb_miss); + /* Clear secpath to prevent invalid dereference + * in downstream XFRM policy checks. + */ + secpath_reset(skb); return; } xfrm_state_hold(sa_entry->x); -- 2.34.1

2 1

[PATCH OLK-6.6 0/5] CVE-2025-38502
by Xiaomeng Zhang 03 Sep '25

03 Sep '25

Daniel Borkmann (4): bpf: Add cookie object to bpf maps bpf: Move bpf map owner out of common struct bpf: Move cgroup iterator helpers to bpf.h bpf: Fix oob access in cgroup local storage Xiaomeng Zhang (1): Fix kabi breakage for bpf_map by using KABI_BROKEN_REPLACE and KABI_FILL_HOLE. include/linux/bpf-cgroup.h | 5 ---- include/linux/bpf.h | 56 ++++++++++++++++++++++++++++---------- kernel/bpf/core.c | 50 ++++++++++++++++++++++------------ kernel/bpf/syscall.c | 19 +++++++++---- 4 files changed, 88 insertions(+), 42 deletions(-) -- 2.34.1

2 6

[PATCH openEuler-1.0-LTS 0/2] Fix CVE-2025-38498
by Long Li 03 Sep '25

03 Sep '25

This patch set fix CVE-2025-38498. Al Viro (2): do_change_type(): refuse to operate on unmounted/not ours mounts use uniform permission checks for all mount propagation changes fs/namespace.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) -- 2.39.2

2 3

[PATCH OLK-6.6 0/5] CVE-2025-38502
by Xiaomeng Zhang 03 Sep '25

03 Sep '25

Daniel Borkmann (4): bpf: Add cookie object to bpf maps bpf: Move bpf map owner out of common struct bpf: Move cgroup iterator helpers to bpf.h bpf: Fix oob access in cgroup local storage Xiaomeng Zhang (1): Fix kabi breakage for bpf_map by using KABI_BROKEN_REPLACE and KABI_FILL_HOLE. include/linux/bpf-cgroup.h | 5 ---- include/linux/bpf.h | 56 ++++++++++++++++++++++++++++---------- kernel/bpf/core.c | 50 ++++++++++++++++++++++------------ kernel/bpf/syscall.c | 19 +++++++++---- 4 files changed, 88 insertions(+), 42 deletions(-) -- 2.34.1

2 6

[PATCH OLK-5.10 0/7] CVE-2025-38502
by Xiaomeng Zhang 03 Sep '25

03 Sep '25

Daniel Borkmann (4): bpf: Add cookie object to bpf maps bpf: Move bpf map owner out of common struct bpf: Move cgroup iterator helpers to bpf.h bpf: Fix oob access in cgroup local storage Toke Hoiland-Jorgensen (1): bpf: generalise tail call map compatibility check Toke Høiland-Jørgensen (1): bpf: Resolve fext program type when checking map compatibility Xiaomeng Zhang (1): Fix kabi breakage for bpf_map by using KABI_FILL_HOLE and KABI_EXTEND include/linux/bpf-cgroup.h | 5 -- include/linux/bpf.h | 90 +++++++++++++++++++++++------------- include/linux/bpf_verifier.h | 5 ++ kernel/bpf/arraymap.c | 4 +- kernel/bpf/core.c | 59 ++++++++++++++--------- kernel/bpf/cpumap.c | 16 ++++--- kernel/bpf/devmap.c | 3 +- kernel/bpf/syscall.c | 22 +++++---- kernel/bpf/verifier.c | 5 -- 9 files changed, 126 insertions(+), 83 deletions(-) -- 2.34.1

2 8

[PATCH openEuler-1.0-LTS] blk-cgroup: Use cond_resched() when destroy blkgs
by Zheng Qixing 03 Sep '25

03 Sep '25

From: Baolin Wang <baolin.wang(a)linux.alibaba.com> mainline inclusion from mainline-v5.11-rc6 commit 6c635caef410aa757befbd8857c1eadde5cc22ed category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICSIDZ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------ On !PREEMPT kernel, we can get below softlockup when doing stress testing with creating and destroying block cgroup repeatly. The reason is it may take a long time to acquire the queue's lock in the loop of blkcg_destroy_blkgs(), or the system can accumulate a huge number of blkgs in pathological cases. We can add a need_resched() check on each loop and release locks and do cond_resched() if true to avoid this issue, since the blkcg_destroy_blkgs() is not called from atomic contexts. [ 4757.010308] watchdog: BUG: soft lockup - CPU#11 stuck for 94s! [ 4757.010698] Call trace: [ 4757.010700] blkcg_destroy_blkgs+0x68/0x150 [ 4757.010701] cgwb_release_workfn+0x104/0x158 [ 4757.010702] process_one_work+0x1bc/0x3f0 [ 4757.010704] worker_thread+0x164/0x468 [ 4757.010705] kthread+0x108/0x138 Suggested-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflicts: block/blk-cgroup.c [Due to not merging commit 0d945c1f966b ("block: remove the queue_lock indirection").] Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- block/blk-cgroup.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c index c0187bf00f71..e10228ffa61f 100644 --- a/block/blk-cgroup.c +++ b/block/blk-cgroup.c @@ -1142,6 +1142,8 @@ static void blkcg_css_offline(struct cgroup_subsys_state *css) */ void blkcg_destroy_blkgs(struct blkcg *blkcg) { + might_sleep(); + spin_lock_irq(&blkcg->lock); while (!hlist_empty(&blkcg->blkg_list)) { @@ -1149,14 +1151,20 @@ void blkcg_destroy_blkgs(struct blkcg *blkcg) struct blkcg_gq, blkcg_node); struct request_queue *q = blkg->q; - if (spin_trylock(q->queue_lock)) { - blkg_destroy(blkg); - spin_unlock(q->queue_lock); - } else { + if (need_resched() || !spin_trylock(q->queue_lock)) { + /* + * Given that the system can accumulate a huge number + * of blkgs in pathological cases, check to see if we + * need to rescheduling to avoid softlockup. + */ spin_unlock_irq(&blkcg->lock); - cpu_relax(); + cond_resched(); spin_lock_irq(&blkcg->lock); + continue; } + + blkg_destroy(blkg); + spin_unlock(q->queue_lock); } spin_unlock_irq(&blkcg->lock); -- 2.39.2

2 1

[PATCH OLK-5.10 0/6] CVE-2025-38502
by Xiaomeng Zhang 03 Sep '25

03 Sep '25

Daniel Borkmann (4): bpf: Add cookie object to bpf maps bpf: Move bpf map owner out of common struct bpf: Move cgroup iterator helpers to bpf.h bpf: Fix oob access in cgroup local storage Toke Hoiland-Jorgensen (1): bpf: generalise tail call map compatibility check Xiaomeng Zhang (1): Fix kabi breakage for bpf_map by using KABI_FILL_HOLE and KABI_EXTEND include/linux/bpf-cgroup.h | 5 --- include/linux/bpf.h | 90 +++++++++++++++++++++++++------------- kernel/bpf/arraymap.c | 4 +- kernel/bpf/core.c | 57 ++++++++++++++---------- kernel/bpf/cpumap.c | 16 ++++--- kernel/bpf/devmap.c | 3 +- kernel/bpf/syscall.c | 22 ++++++---- 7 files changed, 119 insertions(+), 78 deletions(-) -- 2.34.1

2 7