In the Linux kernel, the following vulnerability has been resolved:
fs/smb/client: fix out-of-bounds read in cifssanitizeprepath
When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.
This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.
The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.
crypto: algifaead - Revert to operating out-of-place
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: ndisc: fix ndiscrauseropt to initialize nduseroptpadX fields to zero to prevent an info-leak
When processing Router Advertisements with user options the kernel builds an RTMNEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data
The fix is simple, just zeroes the padding fields.
crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix regsafe() for pointers to packet
In case rold->reg->range == BEYONDPKTEND && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: ensure names are nul-terminated
Reject names that lack a \0 character before feeding them to functions that expect c-strings.
Fixes tag is the most recent commit that needs this change.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfconntrackhelper: pass helper to expect cleanup
nfconntrackhelperunregister() calls nfctexpectiteratedestroy() to remove expectations belonging to the helper being unregistered. However, it passes NULL instead of the helper pointer as the data argument, so expectiterme() never matches any expectation and all of them survive the cleanup.
After unregister returns, nfnlcthelperdel() frees the helper object immediately. Subsequent expectation dumps or packet-driven initconntrack() calls then dereference the freed exp->helper, causing a use-after-free.
Pass the actual helper pointer so expectations referencing it are properly destroyed before the helper object is freed.
BUG: KASAN: slab-use-after-free in string+0x38f/0x430 Read of size 1 at addr ffff888003b14d20 by task poc/103 Call Trace: string+0x38f/0x430 vsnprintf+0x3cc/0x1170 seqprintf+0x17a/0x240 expseqshow+0x2e5/0x560 seqreaditer+0x419/0x1280 procregread+0x1ac/0x270 vfsread+0x179/0x930 ksysread+0xef/0x1c0 Freed by task 103: The buggy address is located 32 bytes inside of freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: ignore explicit helper on new expectations
Use the existing master conntrack helper, anything else is not really supported and it just makes validation more complicated, so just ignore what helper userspace suggests for this expectation.
This was uncovered when validating CTAEXPECTCLASS via different helper provided by userspace than the existing master conntrack helper:
BUG: KASAN: slab-out-of-bounds in nfctexpectrelatedreport+0x2479/0x27c0 Read of size 4 at addr ffff8880043fe408 by task poc/102 Call Trace: nfctexpectrelatedreport+0x2479/0x27c0 ctnetlinkcreateexpect+0x22b/0x3b0 ctnetlinknewexpect+0x4bd/0x5c0 nfnetlinkrcvmsg+0x67a/0x950 netlinkrcvskb+0x120/0x350
Allowing to read kernel memory bytes off the expectation boundary.
CTAEXPECTHELPNAME is still used to offer the helper name to userspace via netlink dump.
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ti-adc161s626: use DMA-safe memory for spiread()
Add a DMA-safe buffer and use it for spiread() instead of a stack memory. All SPI buffers must be DMA-safe.
Since we only need up to 3 bytes, we just use a u8[] instead of be16 and be32 and change the conversion functions appropriately.
In the Linux kernel, the following vulnerability has been resolved:
iio: gyro: mpu3050: Move iiodeviceregister() to correct location
iiodeviceregister() should be at the end of the probe function to prevent race conditions.
Place iiodeviceregister() at the end of the probe function and place iiodeviceunregister() accordingly.
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: flowlabel: defer exclusive option free until RCU teardown
ip6flseqshow() walks the global flowlabel hash under the seq-file RCU read-side lock and prints fl->opt->optnflen when an option block is present.
Exclusive flowlabels currently free fl->opt as soon as fl->users drops to zero in flrelease(). However, the surrounding struct ip6flowlabel remains visible in the global hash table until later garbage collection removes it and flfreercu() finally tears it down.
A concurrent /proc/net/ip6flowlabel reader can therefore race that early kfree() and dereference freed option state, triggering a crash in ip6flseqshow().
Fix this by keeping fl->opt alive until flfreercu(). That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftct: fix use-after-free in timeout object destroy
nftcttimeoutobjdestroy() frees the timeout object with kfree() immediately after nfctuntimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcudereference() in nfcttimeoutdata().
Add an rcuhead to struct nfcttimeout and use kfreercu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlinkcttimeout.c.
KASAN report: BUG: KASAN: slab-use-after-free in nfconntracktcppacket+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80
Call Trace: nfconntracktcppacket+0x1381/0x29d0 nfconntrackin+0x612/0x8b0 nfhookslow+0x70/0x100 iplocalout+0x1b2/0x210 tcpsendmsglocked+0x722/0x1580 syssendto+0x2d8/0x320
Allocated by task 75: nftcttimeoutobjinit+0xf6/0x290 nftobjinit+0x107/0x1b0 nftablesnewobj+0x680/0x9c0 nfnetlinkrcvbatch+0xc29/0xe00
Freed by task 26: nftobjdestroy+0x3f/0xa0 nftablestransdestroywork+0x51c/0x5c0 processonework+0x2c4/0x5a0
In the Linux kernel, the following vulnerability has been resolved:
net: altera-tse: fix skb leak on DMA mapping error in tsestartxmit()
When dmamapsingle() fails in tsestartxmit(), the function returns NETDEVTXOK without freeing the skb. Since NETDEVTXOK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure.
Add devkfreeskbany() before returning to properly free the skb.
In the Linux kernel, the following vulnerability has been resolved:
net: macb: Use devconsumeskbany() to free TX SKBs
The napiconsumeskb() function is not intended to be called in an IRQ disabled context. However, after commit 6bc8a5098bf4 ("net: macb: Fix txptrlock locking"), the freeing of TX SKBs is performed with IRQs disabled. To resolve the following call trace, use devconsumeskbany() for freeing TX SKBs: WARNING: kernel/softirq.c:430 at localbhenableip+0x174/0x188, CPU#0: ksoftirqd/0/15 Modules linked in: CPU: 0 UID: 0 PID: 15 Comm: ksoftirqd/0 Not tainted 7.0.0-rc4-next-20260319-yocto-standard-dirty #37 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : localbhenableip+0x174/0x188 lr : localbhenable+0x24/0x38 sp : ffff800082b3bb10 x29: ffff800082b3bb10 x28: ffff0008031f3c00 x27: 000000000011ede0 x26: ffff000800a7ff00 x25: ffff800083937ce8 x24: 0000000000017a80 x23: ffff000803243a78 x22: 0000000000000040 x21: 0000000000000000 x20: ffff000800394c80 x19: 0000000000000200 x18: 0000000000000001 x17: 0000000000000001 x16: ffff000803240000 x15: 0000000000000000 x14: ffffffffffffffff x13: 0000000000000028 x12: ffff000800395650 x11: ffff8000821d1528 x10: ffff800081c2bc08 x9 : ffff800081c1e258 x8 : 0000000100000301 x7 : ffff8000810426ec x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000008 x1 : 0000000000000200 x0 : ffff8000810428dc Call trace: localbhenableip+0x174/0x188 (P) localbhenable+0x24/0x38 skbattemptdeferfree+0x190/0x1d8 napiconsumeskb+0x58/0x108 macbtxpoll+0x1a4/0x558 napipoll+0x50/0x198 netrxaction+0x1f4/0x3d8 handlesoftirqs+0x16c/0x560 runksoftirqd+0x44/0x80 smpbootthreadfn+0x1d8/0x338 kthread+0x120/0x150 retfromfork+0x10/0x20 irq event stamp: 29751 hardirqs last enabled at (29750): [<ffff8000813be184>] rawspinunlockirqrestore+0x44/0x88 hardirqs last disabled at (29751): [<ffff8000813bdf60>] rawspinlockirqsave+0x38/0x98 softirqs last enabled at (29150): [<ffff8000800f1aec>] handlesoftirqs+0x504/0x560 softirqs last disabled at (29153): [<ffff8000800f2fec>] runksoftirqd+0x44/0x80
futex: Clear stale exiting pointer in futexlockpi() retry path
esp: fix skb leak with espintcp and async crypto
afkey: validate families in pfkeysendmigrate()
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Avoid releasing netdev before teardown completes
The patch cited in the Fixes tag below changed the teardown code for OVS ports to no longer unconditionally take the RTNL. After this change, the netdevdestroy() callback can proceed immediately to the callrcu() invocation if the IFFOVSDATAPATH flag is already cleared on the netdev.
The ovsnetdevdetachdev() function clears the flag before completing the unregistration, and if it gets preempted after clearing the flag (as can happen on an -rt kernel), netdevdestroy() can complete and the device can be freed before the unregistration completes. This leads to a splat like:
[ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el102.x8664+rt #1 PREEMPTRT [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025 [ 998.393889] RIP: 0010:devsetpromiscuity+0x8d/0xa0 [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 <48> 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90 [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246 [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000 [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05 [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000 [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006 [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000 [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000 [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0 [ 998.393944] PKRU: 55555554 [ 998.393946] Call Trace: [ 998.393949] <TASK> [ 998.393952] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393961] ? showtraceloglvl+0x1b0/0x2f0 [ 998.393975] ? dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394009] ? diebody.cold+0x8/0x12 [ 998.394016] ? dieaddr+0x3c/0x60 [ 998.394027] ? excgeneralprotection+0x16d/0x390 [ 998.394042] ? asmexcgeneralprotection+0x26/0x30 [ 998.394058] ? devsetpromiscuity+0x8d/0xa0 [ 998.394066] ? ovsnetdevdetachdev+0x3a/0x80 [openvswitch] [ 998.394092] dpdeviceevent+0x41/0x80 [openvswitch] [ 998.394102] notifiercallchain+0x5a/0xd0 [ 998.394106] unregisternetdevicemanynotify+0x51b/0xa60 [ 998.394110] rtnldellink+0x169/0x3e0 [ 998.394121] ? rtmutexslowlock.constprop.0+0x95/0xd0 [ 998.394125] rtnetlinkrcvmsg+0x142/0x3f0 [ 998.394128] ? avchaspermnoaudit+0x69/0xf0 [ 998.394130] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 998.394132] netlinkrcvskb+0x50/0x100 [ 998.394138] netlinkunicast+0x292/0x3f0 [ 998.394141] netlinksendmsg+0x21b/0x470 [ 998.394145] syssendmsg+0x39d/0x3d0 [ 998.394149] syssendmsg+0x9a/0xe0 [ 998.394156] syssendmsg+0x7a/0xd0 [ 998.394160] dosyscall64+0x7f/0x170 [ 998.394162] entrySYSCALL64afterhwframe+0x76/0x7e [ 998.394165] RIP: 0033:0x7fad61bf4724 [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724 [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003 [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2 ---truncated---
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 smcrxupdateconsumer() 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 piperelease+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 smcspdpriv 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 splicepipetopipe() for partial transfers; both will now return -EFAULT. Users who need to duplicate SMC socket data must use a copy-based read path.
In the Linux kernel, the following vulnerability has been resolved:
net: fix fanout UAF in packetrelease() via NETDEVUP race
packetrelease() has a race window where NETDEVUP can re-register a socket into a fanout group's arr[] array. The re-registration is not cleaned up by fanoutrelease(), leaving a dangling pointer in the fanout array. packetrelease() does NOT zero po->num in its bindlock section. After releasing bindlock, po->num is still non-zero and po->ifindex still matches the bound device. A concurrent packetnotifier(NETDEVUP) that already found the socket in sklist can re-register the hook. For fanout sockets, this re-registration calls fanoutlink(sk, po) which adds the socket back into f->arr[] and increments f->nummembers, but does NOT increment f->skref.
The fix sets po->num to zero in packetrelease while bindlock is held to prevent NETDEVUP from linking, preventing the race window.
This bug was found following an additional audit with Claude Code based on CVE-2025-38617.
In the Linux kernel, the following vulnerability has been resolved:
net: macb: use the current queue number for stats
There's a potential mismatch between the memory reserved for statistics and the amount of memory written.
gemgetssetcount() correctly computes the number of stats based on the active queues, whereas gemgetethtoolstats() indiscriminately copies data using the maximum number of queues, and in the case the number of active queues is less than MACBMAXQUEUES, this results in a OOB write as observed in the KASAN splat.
================================================================== BUG: KASAN: vmalloc-out-of-bounds in gemgetethtoolstats+0x54/0x78 [macb] Write of size 760 at addr ffff80008080b000 by task ethtool/1027
CPU: [...] Tainted: [E]=UNSIGNEDMODULE Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025 Call trace: showstack+0x20/0x38 (C) dumpstacklvl+0x80/0xf8 printreport+0x384/0x5e0 kasanreport+0xa0/0xf0 kasancheckrange+0xe8/0x190 asanmemcpy+0x54/0x98 gemgetethtoolstats+0x54/0x78 [macb 926c13f3af83b0c6fe64badb21ec87d5e93fcf65] devethtool+0x1220/0x38c0 devioctl+0x4ac/0xca8 sockdoioctl+0x170/0x1d8 sockioctl+0x484/0x5d8 arm64sysioctl+0x12c/0x1b8 invokesyscall+0xd4/0x258 el0svccommon.constprop.0+0xb4/0x240 doel0svc+0x48/0x68 el0svc+0x40/0xf8 el0t64synchandler+0xa0/0xe8 el0t64sync+0x1b0/0x1b8
The buggy address belongs to a 1-page vmalloc region starting at 0xffff80008080b000 allocated at devethtool+0x11f0/0x38c0 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff00000a333000 pfn:0xa333 flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff) raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================
Fix it by making sure the copied size only considers the active number of queues.
In the Linux kernel, the following vulnerability has been resolved:
spi: spi-fsl-lpspi: fix teardown order issue (UAF)
There is a teardown order issue in the driver. The SPI controller is registered using devmspiregistercontroller(), which delays unregistration of the SPI controller until after the fsllpspiremove() function returns.
As the fsllpspiremove() function synchronously tears down the DMA channels, a running SPI transfer triggers the following NULL pointer dereference due to use after free:
| fsllpspi 42550000.spi: I/O Error in DMA RX | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] | Call trace: | fsllpspidmatransfer+0x260/0x340 [spifsllpspi] | fsllpspitransferone+0x198/0x448 [spifsllpspi] | spitransferonemessage+0x49c/0x7c8 | spipumptransfermessage+0x120/0x420 | spisync+0x2c4/0x520 | spisync+0x34/0x60 | spidevmessage+0x20c/0x378 [spidev] | spidevioctl+0x398/0x750 [spidev] [...]
Switch from devmspiregistercontroller() to spiregistercontroller() in fsllpspiprobe() and add the corresponding spiunregistercontroller() in fsllpspiremove().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: drop logically empty buckets in mtypedel
mtypedel() counts empty slots below n->pos in k, but it only drops the bucket when both n->pos and k are zero. This misses buckets whose live entries have all been removed while n->pos still points past deleted slots.
Treat a bucket as empty when all positions below n->pos are unused and release it directly instead of shrinking it further.
In the Linux kernel, the following vulnerability has been resolved:
net/x25: Fix overflow when accumulating packets
Add a check to ensure that x25sock.fraglen does not overflow.
The fraglen also needs to be resetted when purging fragmentqueue in x25clearqueues().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlinklog: account for netlink header size
This is a followup to an old bug fix: NLMSGDONE needs to account for the netlink header size, not just the attribute size.
This can result in a WARN splat + drop of the netlink message, but other than this there are no ill effects.
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: serialize lock/unlock against other NAND operations
nandlock() and nandunlock() call into chip->ops.lockarea/unlockarea without holding the NAND device lock. On controllers that implement SETFEATURES via multiple low-level PIO commands, these can race with concurrent UBI/UBIFS background erase/write operations that hold the device lock, resulting in cmdpending conflicts on the NAND controller.
Add nandgetdevice()/nandreleasedevice() around the lock/unlock operations to serialize them against all other NAND controller access.
In the Linux kernel, the following vulnerability has been resolved:
dpaa2-switch: Fix interrupt storm after receiving bad ifid in IRQ handler
Commit 31a7a0bbeb00 ("dpaa2-switch: add bounds check for ifid in IRQ handler") introduces a range check for ifid to avoid an out-of-bounds access. If an out-of-bounds ifid is detected, the interrupt status is not cleared. This may result in an interrupt storm.
Clear the interrupt status after detecting an out-of-bounds ifid to avoid the problem.
Found by an experimental AI code review agent at Google.
In the Linux kernel, the following vulnerability has been resolved:
tls: Purge asynchold in tlsdecryptasyncwait()
The asynchold queue pins encrypted input skbs while the AEAD engine references their scatterlist data. Once tlsdecryptasyncwait() returns, every AEAD operation has completed and the engine no longer references those skbs, so they can be freed unconditionally.
A subsequent patch adds batch async decryption to tlsswreadsock(), introducing a new call site that must drain pending AEAD operations and release held skbs. Move skbqueuepurge(&ctx->asynchold) into tlsdecryptasyncwait() so the purge is centralized and every caller -- recvmsg's drain path, the -EBUSY fallback in tlsdodecryption(), and the new readsock batch path -- releases held skbs on synchronization without each site managing the purge independently.
This fixes a leak when tlsstrpmsghold() fails part-way through, after having added some cloned skbs to the asynchold queue. tlsdecryptsg() will then call tlsdecryptasyncwait() to process all pending decrypts, and drop back to synchronous mode, but tlsswrecvmsg() only flushes the asynchold queue when one record has been processed in "fully-async" mode, which may not be the case here.
[pabeni@redhat.com: added leak comment]
In the Linux kernel, the following vulnerability has been resolved:
nfnetlinkosf: validate individual option lengths in fingerprints
nfnlosfaddcallback() validates optnum bounds and string NUL-termination but does not check individual option length fields. A zero-length option causes nfosfmatchone() to enter the option matching loop even when foptsize sums to zero, which matches packets with no TCP options where ctx->optp is NULL:
Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:nfosfmatchone (net/netfilter/nfnetlinkosf.c:98) Call Trace: nfosfmatch (net/netfilter/nfnetlinkosf.c:227) xtosfmatchpacket (net/netfilter/xtosf.c:32) iptdotable (net/ipv4/netfilter/iptables.c:293) nfhookslow (net/netfilter/core.c:623) iplocaldeliver (net/ipv4/ipinput.c:262) iprcv (net/ipv4/ipinput.c:573)
Additionally, an MSS option (kind=2) with length < 4 causes out-of-bounds reads when nfosfmatchone() unconditionally accesses optp[2] and optp[3] for MSS value extraction. While RFC 9293 section 3.2 specifies that the MSS option is always exactly 4 bytes (Kind=2, Length=4), the check uses "< 4" rather than "!= 4" because lengths greater than 4 do not cause memory safety issues -- the buffer is guaranteed to be at least foptsize bytes by the ctx->optsize == foptsize check.
Reject fingerprints where any option has zero length, or where an MSS option has length less than 4, at add time rather than trusting these values in the packet matching hot path.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: release flowtable after rcu grace period on error
Call synchronizercu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlinkhook control plane.
This error path is rare, it should only happen by reaching the maximum number hooks or by failing to set up to hardware offload, just call synchronizercu().
There is a check for already used device hooks by different flowtable that could result in EEXIST at this late stage. The hook parser can be updated to perform this check earlier to this error path really becomes rarely exercised.
Uncovered by KASAN reported as use-after-free from nfnetlinkhook path when dumping hooks.