CVE-2023-53857
NoneCVSS
—
EPSS
0.2%
Published
Dec 9, 2025
CISA due date
—
Cloudanix analysis
A kernel bug that could cause warning messages or instability when certain network-related programs run was fixed by changing the order of internal locking and memory allocation.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Theoretical
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
The bpf_sk_storage implementation acquires a local_lock while already holding a raw_spin_lock, violating lock ordering rules and triggering invalid wait context reports during kzalloc in tracing contexts.
Why it matters to the business
Systems running BPF programs that update socket or task local storage may experience kernel warnings, potential instability on real-time configurations, and require kernel updates to restore clean operation.
How an attack unfolds
An attacker crafts a tracing BPF program accepted by the verifier that obtains a PTR_TO_BTF_ID sk pointer, then invokes bpf_sk_storage_update while the raw_spin_lock is held, surfacing the lockdep violation; the condition is largely theoretical for production workloads.
How to fix it
Upgrade the Linux kernel to a version containing commit 300415caa373a07782fcbc2f8d9429bc2dc27a47; rebuild and reboot with the patched tree.
How to confirm the fix worked
Confirm the commit hash is present in the running kernel source; execute './test_progs -t test_local_storage' and verify absence of the 'Invalid wait context' splat.
Typical attack path
- Load a verifier-accepted tracing BPF program referencing sk storage
- Trigger map_update_elem on bpf_sk_storage from a context holding rcu_read_lock
- Acquire raw_spin_lock inside bpf_local_storage_update
- Perform kzalloc under the spinlock, violating wait-context rules
How to detect it
Inspect kernel logs for lockdep splats containing 'stock_lock', 'bpf_local_storage_update', or 'Invalid wait context' messages around BPF map operations.
- BUG: Invalid wait context
- stock_lock
- bpf_local_storage_update
- bpf_map_kzalloc
- local_lock_acquire
What your security team should do
- Apply the referenced kernel commit or distribution update within standard patching windows
- Enable lockdep and monitor dmesg for stock_lock or bpf_local_storage_update warnings
- Limit untrusted BPF program loading until kernels are updated
The record
In the Linux kernel, the following vulnerability has been resolved: bpf: bpf_sk_storage: Fix invalid wait context lockdep report './test_progs -t test_local_storage' reported a splat: [ 27.137569] ============================= [ 27.138122] [ BUG: Invalid wait context ] [ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O [ 27.139542] ----------------------------- [ 27.140106] test_progs/1729 is trying to lock: [ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130 [ 27.141834] other info that might help us debug this: [ 27.142437] context-{5:5} [ 27.142856] 2 locks held by test_progs/1729: [ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40 [ 27.144492] #1: ffff888107deb2c0 (&storage->lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0 [ 27.145855] stack backtrace: [ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247 [ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 27.149127] Call Trace: [ 27.149490] <TASK> [ 27.149867] dump_stack_lvl+0x130/0x1d0 [ 27.152609] dump_stack+0x14/0x20 [ 27.153131] __lock_acquire+0x1657/0x2220 [ 27.153677] lock_acquire+0x1b8/0x510 [ 27.157908] local_lock_acquire+0x29/0x130 [ 27.159048] obj_cgroup_charge+0xf4/0x3c0 [ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0 [ 27.161931] __kmem_cache_alloc_node+0x51/0x210 [ 27.163557] __kmalloc+0xaa/0x210 [ 27.164593] bpf_map_kzalloc+0xbc/0x170 [ 27.165147] bpf_selem_alloc+0x130/0x510 [ 27.166295] bpf_local_storage_update+0x5aa/0x8e0 [ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0 [ 27.169199] bpf_map_update_value+0x415/0x4f0 [ 27.169871] map_update_elem+0x413/0x550 [ 27.170330] __sys_bpf+0x5e9/0x640 [ 27.174065] __x64_sys_bpf+0x80/0x90 [ 27.174568] do_syscall_64+0x48/0xa0 [ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 27.175932] RIP: 0033:0x7effb40e41ad [ 27.176357] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d8 [ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141 [ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad [ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002 [ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788 [ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000 [ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000 [ 27.184958] </TASK> It complains about acquiring a local_lock while holding a raw_spin_lock. It means it should not allocate memory while holding a raw_spin_lock since it is not safe for RT. raw_spin_lock is needed because bpf_local_storage supports tracing context. In particular for task local storage, it is easy to get a "current" task PTR_TO_BTF_ID in tracing bpf prog. However, task (and cgroup) local storage has already been moved to bpf mem allocator which can be used after raw_spin_lock. The splat is for the sk storage. For sk (and inode) storage, it has not been moved to bpf mem allocator. Using raw_spin_lock or not, kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context. However, the local storage helper requires a verifier accepted sk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean running a bpf prog in a kzalloc unsafe context and also able to hold a verifier accepted sk pointer) could happen. This patch avoids kzalloc after raw_spin_lock to silent the splat. There is an existing kzalloc before the raw_spin_lock. At that point, a kzalloc is very likely required because a lookup has just been done before. Thus, this patch always does the kzalloc before acq ---truncated---
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Linux | Kernel | 5.18.0 | 6.5.4 |
| SUSE:Linux Enterprise High Availability Extension 15 SP6 | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Live Patching 15 SP6 | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Live Patching 15 SP6 | kernel-livepatch-SLE15-SP6_Update_19 | 0 | 1-150600.13.3.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-64kb | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-default-base | 0 | 6.4.0-150600.23.84.1.150600.12.38.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-docs | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-obs-build | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-source | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-syms | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server 15 SP6-LTSS | kernel-zfcpdump | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-default-base | 0 | 6.4.0-150600.23.84.1.150600.12.38.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-docs | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-obs-build | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-source | 0 | 6.4.0-150600.23.84.1 |
| SUSE:Linux Enterprise Server for SAP Applications 15 SP6 | kernel-syms | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | dtb-aarch64 | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-64kb | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-debug | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-default | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-default-base | 0 | 6.4.0-150600.23.84.1.150600.12.38.1 |
| openSUSE:Leap 15.6 | kernel-docs | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-kvmsmall | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-obs-build | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-obs-qa | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-source | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-syms | 0 | 6.4.0-150600.23.84.1 |
| openSUSE:Leap 15.6 | kernel-zfcpdump | 0 | 6.4.0-150600.23.84.1 |
Related vulnerabilities
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel