CVE-2025-38525

rxrpc: Fix irq-disabled in local_bh_enable()

MEDIUM
5.5
CVSS Score
Published: August 16, 2025 at 11:12 AM UTC
Updated: August 10, 2026 at 01:17 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.5
Exploit prediction
EPSS 0.4%

Description

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix irq-disabled in local_bh_enable() The rxrpc_assess_MTU_size() function calls down into the IP layer to find out the MTU size for a route. When accepting an incoming call, this is called from rxrpc_new_incoming_call() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses local_bh_enable() which, config dependent, throws a warning if IRQs are enabled: WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0 ... RIP: 0010:__local_bh_enable_ip+0x43/0xd0 ... Call Trace: <TASK> rt_cache_route+0x7e/0xa0 rt_set_nexthop.isra.0+0x3b3/0x3f0 __mkroute_output+0x43a/0x460 ip_route_output_key_hash+0xf7/0x140 ip_route_output_flow+0x1b/0x90 rxrpc_assess_MTU_size.isra.0+0x2a0/0x590 rxrpc_new_incoming_peer+0x46/0x120 rxrpc_alloc_incoming_call+0x1b1/0x400 rxrpc_new_incoming_call+0x1da/0x5e0 rxrpc_input_packet+0x827/0x900 rxrpc_io_thread+0x403/0xb60 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 ... hardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50 hardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70 softirqs last enabled at (0): copy_process+0xc61/0x2730 softirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90 Fix this by moving the call to rxrpc_assess_MTU_size() out of rxrpc_init_peer() and further up the stack where it can be done without interrupts disabled. It shouldn't be a problem for rxrpc_new_incoming_call() to do it after the locks are dropped as pmtud is going to be performed by the I/O thread - and we're in the I/O thread at this point.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

6.12.101 ≤ v < 6.12.1036.14 ≤ v < 6.15.86.14 ≤ v < 6.166.6.148 ≤ v < 6.6.1516.12.1016.16 rc16.16 rc26.16 rc36.16 rc46.16 rc56.16 rc66.6.14877433b730970ca6e51d03016e830d8ab1b22685a9c59a82298f424f6212c67fbea531853e88ce6ca2ea9a9072607c2fd6442bd1ffb4dbdbf882aed7
Vendor states this is fixed in 2029f21f10dedb88c0f86abffcf8d6c21dcf6040 (fixed)
Vendor states this is fixed in 8ac0b3baa7d8f732bd9e5cbf1d8b57e4802c6b36 (fixed)
Vendor states this is fixed in d94b82d452ca27a200cd67660dc48476386651d8 (fixed)
Vendor states this is fixed in e4d2878369d590bf8455e3678a644e503172eafa (fixed)
Vendor states this is fixed in 6.12.103 (unaffected)
Vendor states this is fixed in 6.14 (unaffected)
Vendor states this is fixed in 6.15.8 (unaffected)
Vendor states this is fixed in 6.16 (unaffected)
Vendor states this is fixed in 6.6.151 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet. What the record does show:

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
NONE
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
NVD-CWE-noinfo

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card