Cloudanix VulnDB

CVE-2025-38324

None

CVSS

—

EPSS

0.2%

Published

Jul 10, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's handling of certain network routes could let attackers interfere with system stability or gain elevated access, so administrators should install the latest kernel updates.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Low
Patch risk
None

What it actually does

Incorrect RCU dereference check in mpls_route_input_rcu() when invoked from mpls_getroute() under RTNL, allowing potential use-after-free or inconsistent MPLS platform_label access during concurrent updates.

Why it matters to the business

Linux systems handling MPLS traffic face elevated risk of kernel panics or degraded network stability; organizations running affected kernels should prioritize patching to avoid operational disruptions in routing environments.

How an attack unfolds

An attacker triggers mpls_getroute() while holding RTNL to force the suspicious RCU path in mpls_route_input_rcu(), racing against platform_label updates to induce memory corruption or denial of service; listed threat actors in Linux kernel privilege-escalation campaigns could chain this with other kernel flaws for escalation.

How to fix it

Upgrade affected Linux kernels to fixed versions including linux-lts (Alpaquita:23) 6.1.81-r0, linux-lts (Alpaquita:stream) 6.1.81-r0, or mainline commit 2919297b18e5a5fb7e643f9e32c12c0b17cce1be; rebuild and reboot systems after applying the update.

How to confirm the fix worked

Verify kernel version or git commit matches a fixed release; run lockdep-enabled kernels and confirm absence of the RCU suspicious usage splat in mpls_route_input_rcu() during rtnetlink operations.

Typical attack path

  1. Obtain local or network-adjacent access to a system with MPLS enabled
  2. Invoke rtnetlink operations that call mpls_getroute() under rtnl_lock
  3. Concurrently trigger MPLS route updates to race the RCU-protected read
  4. Trigger kernel warnings or memory safety violations leading to crash or code execution

How to detect it

Search kernel logs for RCU usage warnings referencing mpls_route_input_rcu and af_mpls.c:84; monitor rtnetlink traffic and MPLS route changes for anomalous patterns that coincide with the reported lockdep splat.

What your security team should do

  • Apply the listed kernel updates immediately on all MPLS-enabled systems
  • Monitor for new Linux kernel releases containing the RCU fix
  • Disable MPLS if not required to reduce attack surface until patched
  • Audit network configurations for unnecessary MPLS usage

The record

In the Linux kernel, the following vulnerability has been resolved: mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu(). As syzbot reported [0], mpls_route_input_rcu() can be called from mpls_getroute(), where is under RTNL. net->mpls.platform_label is only updated under RTNL. Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() to silence the splat. [0]: WARNING: suspicious RCU usage 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ---------------------------- net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961 stack backtrace: CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0a2818e969 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969 RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003 RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268 </TASK>

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 linux 0 No fix
Debian:12 linux 0 No fix
Debian:13 linux 0 6.12.35-1
Debian:14 linux 0 6.12.35-1
Linux Kernel 4.1.0 5.4.295
Mageia:9 kernel 0 6.6.101-1.mga9
Mageia:9 kernel-linus 0 6.6.101-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.10-7.mga9
Mageia:9 kmod-xtables-addons 0 3.24-83.mga9
Mageia:9 wireless-regdb 0 20250710-1.mga9

Related vulnerabilities