CVE-2026-31507

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

net/smc: fix double-free of smcspdpriv when tee() duplicates splice pipe buffer

smcrxsplice() allocates one smcspdpriv per pipebuffer and stores the pointer in pipebuffer.private. The pipebufoperations for these buffers used .get = genericpipebufget, which only increments the page reference count when tee(2) duplicates a pipe buffer. The smcspdpriv pointer itself was not handled, so after tee() both the original and the cloned pipebuffer share the same smcspdpriv *.

When both pipes are subsequently released, smcrxpipebufrelease() is called twice against the same object:

1st call: kfree(priv) sockput(sk) smcrxupdatecons() [correct] 2nd call: kfree(priv) sockput(sk) smcrxupdatecons() [UAF]

KASAN reports a slab-use-after-free in smcrxpipebufrelease(), which then escalates to a NULL-pointer dereference and kernel panic via smcrxupdate_consumer() when it chases the freed priv->smc pointer:

BUG: KASAN: slab-use-after-free in smcrxpipebufrelease+0x78/0x2a0 Read of size 8 at addr ffff888004a45740 by task smcsplicetee_/74 Call Trace: <TASK> dumpstacklvl+0x53/0x70 printreport+0xce/0x650 kasanreport+0xc6/0x100 smcrxpipebufrelease+0x78/0x2a0 freepipeinfo+0xd4/0x130 pipe_release+0x142/0x160 __fput+0x1c6/0x490 __x64sysclose+0x4f/0x90 dosyscall64+0xa6/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

BUG: kernel NULL pointer dereference, address: 0000000000000020 RIP: 0010:smcrxupdateconsumer+0x8d/0x350 Call Trace: <TASK> smcrxpipebufrelease+0x121/0x2a0 freepipeinfo+0xd4/0x130 piperelease+0x142/0x160 __fput+0x1c6/0x490 __x64sysclose+0x4f/0x90 dosyscall64+0xa6/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> Kernel panic - not syncing: Fatal exception

Beyond the memory-safety problem, duplicating an SMC splice buffer is semantically questionable: smcrxupdatecons() would advance the consumer cursor twice for the same data, corrupting receive-window accounting. A refcount on smcspd_priv could fix the double-free, but the cursor-accounting issue would still need to be addressed separately.

The .get callback is invoked by both tee(2) and splicepipeto_pipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.