Answer in brief
CVE-2025-38525 records a High severity (CVSS 7.5) vulnerability in rxrpc: Fix irq-disabled in local_bh_enable(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=a2ea9a9072607c2fd6442bd1ffb4dbdbf882aed7 <2029f21f10dedb88c0f86abffcf8d6c21dcf6040 || >=a2ea9a9072607c2fd6442bd1ffb4dbdbf882aed7 <e4d2878369d590bf8455e3678a644e503172eafa || 77433b730970ca6e51d03016e830d8ab1b22685a || 09c59a82298f424f6212c67fbea531853e88ce6c || >=6.6.148 <6.7 || >=6.12.101 <6.13 | 2029f21f10dedb88c0f86abffcf8d6c21dcf6040, e4d2878369d590bf8455e3678a644e503172eafa, 6.7, 6.13 |
| Linux/Linuxgeneric | 6.14 | Not reported |
Published upstream
Aug 16, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 3, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 3, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2025-38525 records a High severity (CVSS 7.5) vulnerability in rxrpc: Fix irq-disabled in local_bh_enable(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=a2ea9a9072607c2fd6442bd1ffb4dbdbf882aed7 <2029f21f10dedb88c0f86abffcf8d6c21dcf6040 || >=a2ea9a9072607c2fd6442bd1ffb4dbdbf882aed7 <e4d2878369d590bf8455e3678a644e503172eafa || 77433b730970ca6e51d03016e830d8ab1b22685a || 09c59a82298f424f6212c67fbea531853e88ce6c || >=6.6.148 <6.7 || >=6.12.101 <6.13 | 2029f21f10dedb88c0f86abffcf8d6c21dcf6040, e4d2878369d590bf8455e3678a644e503172eafa, 6.7, 6.13 |
| Linux/Linuxgeneric | 6.14 | Not reported |
Published upstream
Aug 16, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 3, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 3, 2026
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.
Quoted source text, attributed separately from HOL analysis.