CVE-2025-38525

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

rxrpc: Fix irq-disabled in localbhenable()

The rxrpcassessMTUsize() 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 rxrpcnewincomingcall() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses localbhenable() which, config dependent, throws a warning if IRQs are enabled:

WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 localbhenableip+0x43/0xd0 ... RIP: 0010:localbhenableip+0x43/0xd0 ... Call Trace: <TASK> rtcacheroute+0x7e/0xa0 rtsetnexthop.isra.0+0x3b3/0x3f0 _mkrouteoutput+0x43a/0x460 iprouteoutputkeyhash+0xf7/0x140 iprouteoutputflow+0x1b/0x90 rxrpcassessMTUsize.isra.0+0x2a0/0x590 rxrpcnewincomingpeer+0x46/0x120 rxrpcallocincomingcall+0x1b1/0x400 rxrpcnewincomingcall+0x1da/0x5e0 rxrpcinputpacket+0x827/0x900 rxrpciothread+0x403/0xb60 kthread+0x2f7/0x310 retfromfork+0x2a/0x230 retfromforkasm+0x1a/0x30 ... hardirqs last enabled at (23): rawspinunlockirq+0x24/0x50 hardirqs last disabled at (24): rawreadlockirq+0x17/0x70 softirqs last enabled at (0): copyprocess+0xc61/0x2730 softirqs last disabled at (25): rtadduncachedlist+0x3c/0x90

Fix this by moving the call to rxrpcassessMTUsize() out of rxrpcinit_peer() and further up the stack where it can be done without interrupts disabled.

It shouldn't be a problem for rxrpcnewincoming_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.