Skip to main content

Linux Kernel CVE-2025-40041

HIGH
2025-10-28 416baaa9-dc9f-4396-8d5f-8c081fb06d67
7.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
5.5 MEDIUM

Local privileged BPF loading (PR:L) triggers a reproducible kernel panic; observed impact is availability (A:H), with no demonstrated confidentiality or integrity compromise.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 07:55 vuln.today
CVE Published
Oct 28, 2025 - 12:15 cve.org
HIGH 7.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: BPF: Sign-extend struct ops return values properly

The ns_bpf_qdisc selftest triggers a kernel panic:

Oops[#1]: CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era 90000000851b5ac0, ra 90000000851b5aa4 CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G OE 6.16.0+ #3 PREEMPT(full) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600 a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008 a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000 t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001 t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800 s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880 s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000 ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8 ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000741d58 PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)] Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956) Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8 90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000 900000010597c400 900000008694a000 0000000000000000 9000000105b59000 90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c 9000000086936000 0000000100094d4c fffffff400676208 0000000000000000 9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000 9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000 9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840 0000000000000000 9000000086be6c40 0000000000000000 0000000000000000 0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4 ... Call Trace: [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8 [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0 [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950 [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448 [<9000000085370b24>] ip6_xmit+0x304/0x858 [<90000000853c4438>] inet6_csk_xmit+0x100/0x170 [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0 [<90000000852b47fc>] tcp_connect+0xbcc/0x1168 [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0 [<90000000852e7738>] __inet_stream_connect+0x170/0x480 [<90000000852e7a98>] inet_stream_connect+0x50/0x88 [<90000000850f2814>] __sys_connect+0xe4/0x110 [<90000000850f2858>] sys_connect+0x18/0x28 [<9000000085520c94>] do_syscall+0x94/0x1a0 [<9000000083df1fb8>] handle_syscall+0xb8/0x158

Code: 4001ad80 2400873f 2400832d <240073cc> 001137ff 001133ff 6407b41f 001503cc 0280041d

---[ end trace 0000000000000000 ]---

The bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer is treated as a 32bit value and sign extend to 64bit in epilogue. This behavior is right for most bpf prog types but wrong for struct ops which requires LoongArch ABI.

So let's sign extend struct ops return values according to the LoongArch ABI ([1]) and return value spec in function model.

[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

AnalysisAI

Kernel panic (denial of service) in the Linux kernel's LoongArch BPF JIT compiler affects systems running on LoongArch (Loongson) 64-bit CPUs when BPF struct_ops programs - such as a BPF-based qdisc - are attached and their pointer return values are consumed by the kernel networking path. The LoongArch JIT epilogue sign-extended 32-bit return values as it does for ordinary BPF programs, but struct_ops functions must follow the LoongArch calling ABI, so a returned pointer (e.g. an skb from bpf_fifo_dequeue) was truncated/sign-extended into an invalid address that the kernel then dereferenced, causing an unhandled paging fault in __qdisc_run(). This is no public exploit identified at time of analysis and is not on CISA KEV; EPSS is low (0.19%, 9th percentile).

Technical ContextAI

The flaw lives in the LoongArch eBPF JIT compiler (arch/loongarch/net) inside the Linux kernel. eBPF program return values are 32-bit by convention and the JIT epilogue sign-extends them to 64-bit, which is correct for classic BPF program types. However, BPF struct_ops programs (the mechanism that lets BPF implement kernel operation structures such as a scheduling qdisc via bpf_qdisc) must honor the native LoongArch ELF psABI return-value rules, under which a pointer is a full 64-bit value. Sign-extending a 64-bit pointer from its low 32 bits corrupts the high bits, yielding a bogus kernel virtual address. When __qdisc_run() dereferences the returned skb pointer, the CPU takes a paging fault (BADV shows a corrupted address). No CWE was assigned by NVD, but the root cause is an incorrect integer/pointer sign-extension (a truncation/type-confusion of a pointer return value) specific to the LoongArch ABI. The fix sign-extends struct_ops return values according to the LoongArch ABI and the function model's return-value specification.

Affected ProductsAI

The affected product is the Linux kernel, specifically the LoongArch (Loongson 64-bit, e.g. Loongson-3A5000) architecture eBPF JIT; the panic was reproduced on kernel 6.16.0+ via the ns_bpf_qdisc selftest. No CPE strings were provided in the intelligence, so exact vulnerable version ranges are not enumerated by NVD here; the fix is delivered through stable-tree commits. Only builds targeting LoongArch with BPF struct_ops/bpf_qdisc support are affected - x86, arm64, and other architectures are not impacted by this JIT-specific defect. Upstream fix commits: https://git.kernel.org/stable/c/8b51b11b3d81c1ed48a52f87da9256d737b723a0 and https://git.kernel.org/stable/c/9f3169bb3c2967166b4f4433cf152a84f3eb95d0.

RemediationAI

Upstream fix available (commits); released patched version not independently confirmed - apply the stable-tree commits 8b51b11b3d81c1ed48a52f87da9256d737b723a0 and 9f3169bb3c2967166b4f4433cf152a84f3eb95d0 (git.kernel.org/stable) or update to the LoongArch stable/distribution kernel that incorporates them once your vendor ships it. As a compensating control until patched, prevent loading of BPF struct_ops/qdisc programs on LoongArch hosts by restricting the CAP_BPF and CAP_NET_ADMIN capabilities and setting kernel.unprivileged_bpf_disabled=1, and avoid attaching BPF-based qdiscs (bpf_qdisc) in production - the trade-off is loss of any legitimate BPF qdisc/traffic-scheduling functionality and tighter capability policies for container/network tooling. Since the impact is a kernel panic, also ensure watchdog/auto-reboot and workload redundancy are in place to limit downtime.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected

Share

CVE-2025-40041 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy