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

crypto: marvell/octeontx - fix DMA cleanup using wrong loop index

The sgcleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.

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

net: serialize netifrunning() check in enqueuetobacklog()

Syzbot reported a KASAN slab-use-after-free in fibruleslookup().

The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit).

Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration") introduced a lockless netifrunning() check in enqueuetobacklog() to prevent queuing packets to an unregistering device.

However, this creates a TOCTOU race window.

A lockless transmitter (like vethxmit) can pass the check before devclose() clears IFFUP. If the transmitter is then delayed, flushallbacklogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed.

Fix this by moving the netifrunning() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netifrunning() after the flush/close completes (so it gets dropped).

apparmor: fix use-after-free in rawdata dedup loop

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

block: recompute nrintegritysegments in blkinsertclonedrequest

blkinsertclonedrequest() already recomputes nrphyssegments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virtboundarymask, segboundarymask, or maxsegmentsize than the top queue, in which case blkrqcountintegritysg() against the bottom queue produces a different count than the cached rq->nrintegritysegments inherited from the source request by blkrqprepclone().

When the cached count is lower than the bottom queue's actual count, blkrqmapintegritysg() trips

BUGON(segments > rq->nrintegritysegments);

on dispatch. The same families of stacked setups that motivated the existing nrphyssegments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this.

Mirror the nrphyssegments handling: when the request carries integrity, recompute nrintegritysegments against the bottom queue and reject the request if it exceeds the bottom queue's maxintegritysegments. blkrqcountintegritysg() and queuemaxintegritysegments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes.

This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.

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

KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry

vgicitsinvalidatecache() walks the per-ITS translation cache with xaforeach() and drops the cache's reference on each entry with vgicputirq(). It puts the iterated pointer, though, rather than the value returned by xaerase().

The function is called from contexts that do not exclude one another: the ITS command handlers hold itslock, the GITSCTLR write path holds cmdlock, and the path that clears EnableLPIs in a redistributor's GICRCTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it.

xaerase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.

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

powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW

Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing.

These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range.

The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below

BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Hash SMP NRCPUS=2048 NUMA pSeries Modules linked in: afpacket rfkill ibmveth(X) lpfc(+) nvmetfc nvmet nvmekeyring crct10difvpmsum nvmefc nvmefabrics nvmecore be2net(+) nvmeauth rtcgeneric nfsd authrpcgss nfsacl lockd grace sunrpc fuse configfs iptables xtables xfs libcrc32c dmservicetime ibmvfc(X) scsitransportfc vmxcrypto gf128mul crc32cvpmsum dmmirror dmregionhash dmlog dmmultipath dmmod sdmod scsidhemc scsidhrdac scsidhalua t10pi crc64rocksoftgeneric crc64rocksoft sg crc64 scsimod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950149) hv:phyp pSeries Workqueue: events workforcpufn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommutablereservepages+0xac/0x100 LR [c00000000005e830] iommuinittable+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommuinittable+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommubypasssupportedpSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dmaiommudmasupported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dmasupported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dmasetmask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] beprobe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] localpciprobe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] workforcpufn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] processonework+0x314/0x620 [c00001400c9fff10] [c00000000018f280] workerthread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] startkernelthread+0x14/0x18

There are 2 issues in the code

1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap.

2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.

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

tipc: fix slab-use-after-free Read in tipcaeaddecryptdone

tipcaeaddecrypt() goes straight from tipcbearerhold(b) to cryptoaeaddecrypt(req) without taking a reference on the netns, unlike the encrypt path. When cryptoaeaddecrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipcaeaddecryptdone() later. If the bearer's netns is torn down in the meantime, cleanupnet() -> tipcexitnet() -> tipccryptostop() frees the per-netns tipccrypto, and the completion then reads it: tipcaeaddecryptdone() dereferences aead->crypto->stats and aead->crypto->net, and tipccryptorcvcomplete() dereferences aead->crypto->aead[] and the node table -- reading freed memory.

Decoded KASAN splat (v7.1-rc7, CONFIGKASANINLINE + TIPC + TIPCCRYPTO):

BUG: KASAN: slab-use-after-free in tipcaeaddecryptdone (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: eventsunbound Call Trace: tipcaeaddecryptdone (net/tipc/crypto.c:999) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

Allocated by task 169: kasankmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipccryptostart (net/tipc/crypto.c:1502) tipcinitnet (net/tipc/core.c:72) opsinit (net/core/netnamespace.c:137) setupnet (net/core/netnamespace.c:446) copynetns (net/core/netnamespace.c:579) createnewnamespaces (kernel/nsproxy.c:132) x64sysunshare (kernel/fork.c:3316) dosyscall64 (arch/x86/entry/syscall64.c:63) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)

Freed by task 8: kfree (mm/slub.c:6566) tipcexitnet (net/tipc/core.c:119) cleanupnet (net/core/netnamespace.c:704) processonework (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436)

This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipcaeadencryptdone") fixed for the encrypt side. The encrypt path takes maybegetnet(aead->crypto->net) before cryptoaeadencrypt() and drops it with putnet() on the synchronous return paths and in tipcaeadencryptdone(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard.

Mirror the encrypt-side fix on the decrypt path: take a net reference before cryptoaeaddecrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with putnet() on the synchronous success/error return and at the end of tipcaeaddecryptdone().

Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipccryptostop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipcaeaddecryptdone() is the unpatched upstream path; tipcaeaddecrypt() still lacks maybegetnet(aead->crypto->net), so the completion can outlive the free on any config where cryptoaeaddecrypt() goes async.

Found by 0sec automated security-research tooling (https://0sec.ai).

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

Bluetooth: hcisync: Fix advertising data UAFs

hcifindadvinstance() returns an advinfo pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response.

An advertising termination event can therefore interleave as follows:

hcicmdsyncwork hcirxwork hcifindadvinstance() hcicmdsyncstatus() wait for controller reply hcidevlock() hciremoveadvinstance() kfree(adv) adv->scanrspchanged = false

KASAN reported:

BUG: KASAN: slab-use-after-free in hcisetextscanrspdatasync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hcicmdsyncwork Call Trace: hcisetextscanrspdatasync+0x2e1/0x300 hcischeduleadvinstancesync+0x390/0x4c0 hcicmdsyncwork+0x173/0x300 Allocated by task 87: hciaddadvinstance+0x538/0xac0 addadvertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hciremoveadvinstance+0x1d8/0x3b0 hcileextadvtermevt+0x17b/0x730

Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller.

Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No advinfo pointer then survives an HCI command wait.

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

iouring/zcrx: fix overshooting recv limit

It's reported that sometimes a zcrx request can receive more than was requested. It's caused by iozcrxrecvskb() adjusting desc->count for all received buffers including frag lists, but then doing recursive calls to process frag list skbs, which leads to desc->count double accounting and underflow.

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

nvme-pci: fix out-of-bounds access in nvmesetupdescriptorpools

nvmesetupdescriptorpools() indexes dev->descriptorpools[] using the numanode forwarded from hctx->numanode by its single caller, nvmeinithctxcommon(). On a non-NUMA kernel hctx->numanode is NUMANONODE (-1). Because the parameter was declared 'unsigned', the value becomes UINTMAX and the index walks off the array (sized to nrnodeids), faulting during nvmeallocns() and leaving the namespace without a /dev node.

Reproduces on any NVMe controller probed by a CONFIGNUMA=n kernel:

BUG: unable to handle page fault for address: ffff889101603d38 RIP: 0010:nvmeinithctxcommon+0x5a/0x190 [nvme] Call Trace: nvmeinithctx+0x10/0x20 [nvme] nvmeallocns+0x9e/0xa10 [nvmecore] nvmescanns+0x301/0x3b0 [nvmecore] nvmescannsasync+0x23/0x30 [nvmecore]

Switch the parameter to int and fall back to node 0 when it is NUMANONODE; node 0 is always present.

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

ipv4: icmp: validate reply type before using icmppointers

Extended echo replies use ICMPEXTECHOREPLY as the outbound reply type. That value is outside the range covered by icmppointers[], which only describes the traditional ICMP types up to NRICMPTYPES.

Avoid consulting icmppointers[] for reply types outside that range, and use arrayindexnospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.

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

reftracker: implement use-after-free detection

Whenever reftrackerdirinit() is called, mark the struct reftrackerdir as dead.

Test the dead status from reftrackeralloc() and reftrackerfree()

This should detect buggy devput()/devhold() happening too late in netdevice dismantle process.

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

net: stmmac: fix dma queue left shift overflow issue

When queue number is > 4, left shift overflows due to 32 bits integer variable. Mask calculation is wrong for MTLRXQDMAMAP1.

If CONFIGUBSAN is enabled, kernel dumps below warning: [ 10.363842] ================================================================== [ 10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/ linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4core.c:224:12 [ 10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int' [ 10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg [ 10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021 [ 10.363958] Call Trace: [ 10.363960] <TASK> [ 10.363963] dumpstacklvl+0x4a/0x5f [ 10.363971] dumpstack+0x10/0x12 [ 10.363974] ubsanepilogue+0x9/0x45 [ 10.363976] ubsanhandleshiftoutofbounds.cold+0x61/0x10e [ 10.363979] ? wakeupklogd+0x4a/0x50 [ 10.363983] ? vprintkemit+0x8f/0x240 [ 10.363986] dwmac4mapmtldma.cold+0x42/0x91 [stmmac] [ 10.364001] stmmacmtlconfiguration+0x1ce/0x7a0 [stmmac] [ 10.364009] ? dwmac410dmainitchannel+0x70/0x70 [stmmac] [ 10.364020] stmmachwsetup.cold+0xf/0xb14 [stmmac] [ 10.364030] ? pagepoolallocpages+0x4d/0x70 [ 10.364034] ? stmmaccleartxdescriptors+0x6e/0xe0 [stmmac] [ 10.364042] stmmacopen+0x39e/0x920 [stmmac] [ 10.364050] devopen+0xf0/0x1a0 [ 10.364054] devchangeflags+0x188/0x1f0 [ 10.364057] devchangeflags+0x26/0x60 [ 10.364059] dosetlink+0x908/0xc40 [ 10.364062] ? dosetlink+0xb10/0xc40 [ 10.364064] ? nlavalidateparse+0x4c/0x1a0 [ 10.364068] rtnlnewlink+0x597/0xa10 [ 10.364072] ? nlareserve+0x41/0x50 [ 10.364074] ? kmallocnodetrackcaller+0x1d0/0x4d0 [ 10.364079] ? pskbexpandhead+0x75/0x310 [ 10.364082] ? nlareserve64bit+0x21/0x40 [ 10.364086] ? skbfreehead+0x65/0x80 [ 10.364089] ? securitysockrcvskb+0x2c/0x50 [ 10.364094] ? condresched+0x19/0x30 [ 10.364097] ? kmemcachealloctrace+0x15a/0x420 [ 10.364100] rtnlnewlink+0x49/0x70

This change fixes MTLRXQDMAMAP1 mask issue and channel/queue mapping warning.

BugLink: https://bugzilla.kernel.org/showbug.cgi?id=216195

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

net: davicom: fix UAF in dm9000drvremove

dm is netdev private data and it cannot be used after freenetdev() call. Using dm after freenetdev() can cause UAF bug. Fix it by moving freenetdev() at the end of the function.

This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emacremove").

This bug is detected by our static analysis tool.

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

scsi: smartpqi: Fix smpprocessorid() call trace for preemptible kernels

Correct kernel call trace when calling smpprocessorid() when called in preemptible kernels by using rawsmpprocessorid().

smpprocessorid() checks to see if preemption is disabled and if not, issue an error message followed by a call to dumpstack().

Brief example of call trace: kernel: checkpreemptiondisabled: 436 callbacks suppressed kernel: BUG: using smpprocessorid() in preemptible [00000000] code: kworker/u1025:0/2354 kernel: caller is pqiscsiqueuecommand+0x183/0x310 [smartpqi] kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0 kernel: ... kernel: Workqueue: writeback wbworkfn (flush-253:0) kernel: Call Trace: kernel: <TASK> kernel: dumpstacklvl+0x34/0x48 kernel: checkpreemptiondisabled+0xdd/0xe0 kernel: pqiscsiqueuecommand+0x183/0x310 [smartpqi] kernel: ...

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

drm/imagination: Fix double call to drmschedentityfini()

Call sequence of double call: pvrcontextdestroy   pvrcontextkillqueues     pvrqueuekill       drmschedentitydestroy         drmschedentityfini // here   pvrcontextput     krefput(..., pvrcontextrelease)       pvrcontextdestroyqueues         pvrqueuedestroy           drmschedentityfini // here

Call to drmschedentitydestroy() from pvrcontextkillqueues() calls drmschedentityflush() + drmschedentityfini(). drmschedentityflush() ensures all pending jobs are completed and drmschedentityfini() ensures no further submission is allowed as per expectation from pvrcontextkillqueues(). Double call to drmschedentityfini() is misuse of the API so keep call only in pvrcontextcreate() failure path.

Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 ("drm/sched: Account entity GPU time"):

[ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcountt: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcountwarnsaturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drmgpuvm drmexec gpusched drmshmemhelper xhciplathcd xhcihcd dwc3 usbcore usbcommon sndsocsimplecard sndsocsimplecardutils sa2ul sha512 sha256 dwc3am62 sha1 authenc rtiwdt libsha512 at24 schfqcodel fuse dmmod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvrqueuefencereleasework [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcountwarnsaturate+0xf4/0x144 [ 789.490884] lr : refcountwarnsaturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcountwarnsaturate+0xf4/0x144 (P) [ 789.491043] drmschedentityfini+0x164/0x18c [gpusched] [ 789.491081] pvrqueuedestroy+0x64/0x134 [powervr] [ 789.491110] pvrcontextdestroyqueues+0x34/0x64 [powervr] [ 789.491138] pvrcontextrelease+0x70/0xac [powervr] [ 789.491166] pvrcontextput.part.0+0x5c/0x7c [powervr] [ 789.491193] pvrcontextput+0x14/0x24 [powervr] [ 789.491221] pvrqueuefencereleasework+0x20/0x38 [powervr] [ 789.491249] processonework+0x160/0x4c4 [ 789.491264] workerthread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] retfromfork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---

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

xfrm: clear mode callbacks after failed mode setup

xfrmstategctask can run long after a failed IPTFS state setup. In the reproduced case, xfrminitstate() cached x->modecbs, IPTFS setup returned -ENOMEM before publishing modedata, and the temporary module reference from xfrmgetmodecbs() was dropped immediately. The dead state then kept x->modecbs until deferred GC ran after xfrmiptfs had been unloaded.

Clear x->modecbs when mode init or clone fails before publishing modedata. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference.

The buggy scenario involves two paths, with each column showing the order within that path:

failed setup path: 1. cache x->modecbs 2. mode setup fails before modedata 3. drop the temporary module ref 4. dead state keeps x->modecbs cached

GC/unload path: 1. xfrmstateput() queues GC work 2. xfrmiptfs unloads later 3. xfrmstategctask runs 4. GC dereferences stale x->modecbs

This also covers the failed clone path where clonestate() returns before publishing modedata.

Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIGFAULTINJECTIONSTACKTRACEFILTER=y failslabstacktracefilter matched xfrmiptfs frames ackerror=-12 FAULTINJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrmstategctask RIP: xfrmstategctask+0x142/0x650 Modules linked in: esp4offload xfrmuser [last unloaded: xfrmiptfs] Kernel panic - not syncing: Fatal exception

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

handshake: Require admin permission for DONE command

ACCEPT and DONE are the two downcalls of the handshake genl family, both intended for use by the trusted handshake agent (tlshd). ACCEPT already requires GENLADMINPERM; DONE has no privilege check at all.

The fd-lookup in handshakenldonedoit() only confirms that some pending handshake request exists for the supplied sockfd; it does not authenticate the sender. An unprivileged process that guesses or observes a valid sockfd can therefore submit a DONE with HANDSHAKEADONESTATUS == 0, leaving the kernel consumer to proceed as if the handshake succeeded. A non-zero status on a forged DONE tears down a legitimate in-flight handshake before tlshd can report its real result.

batman-adv: tpmeter: avoid divide-by-zero for deccwnd

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

wifi: iwlwifi: mld: stop TX during firmware restart

When iwlwifi firmware crashes (e.g., NMIINTERRUPTUNKNOWN on Intel BE201/Wi-Fi 7), iwlmldnicerror() sets mld->fwstatus.inhwrestart to true. However, iwlmldtxfromtxq() does not check this flag before dequeuing frames from mac80211 and pushing them to the transport layer.

Since the firmware is dead, iwltranstx() returns -EIO for each frame, which then gets freed immediately. Under high-throughput conditions (e.g., Tailscale UDP traffic or active SSH sessions), this creates a tight dequeue-send-fail-free loop that wastes CPU cycles and generates rapid skb allocation churn, leading to memory pressure from slab fragmentation.

The RX path already has this guard (iwlmldrxmpdu checks inhwrestart at rx.c:1906), and so does the TXQ allocation worker (iwlmldaddtxqswk at tx.c:156). Add the same guard to iwlmldtxfromtxq() to stop all TX during firmware restart.

Frames left in mac80211's TXQs are naturally drained after restart completes, when queue reallocation triggers iwlmldtxfromtxq() via iwlmldaddtxqlist(), or when new upper-layer traffic invokes waketxqueue.

Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on kernel 6.19.5 where the firmware crashes approximately every 10-15 minutes under Tailscale traffic.

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

ksmbd: fix null pointer dereference in compareguidkey()

sessionfdcheck() walks the per-inode moplist during durable-handle session teardown and sets op->conn = NULL for every opinfo whose conn matched the closing session's connection. The matching opinfo, however, stays linked in its per-ClientGuid leasetablelist entry's lb->leaselist because destroyleasetable() only runs on full TCP-connection teardown, not on SESSIONLOGOFF.

If the same TCP connection then negotiates a fresh session with the same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a lease context on a different inode, findsameleasekey() walks lb->leaselist, reaches the stale opinfo, and calls compareguidkey(), which unconditionally dereferences opinfo->conn->ClientGUID. The conn pointer is NULL and the kernel panics.

Reproducer requires only a successful SMB2 SESSIONSETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194:

general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f] Workqueue: ksmbd-io handleksmbdwork RIP: 0010:bcmp+0x5b/0x230 Call Trace: compareguidkey+0x4b/0xd0 findsameleasekey+0x324/0x690 smb2open+0x6aea/0x8e60 handleksmbdwork+0x796/0xee0 ...

Faulting address 0x348 is the offset of ClientGUID within struct ksmbdconn, confirming opinfo->conn was NULL.

Read opinfo->conn once and bail out if it has been cleared by a concurrent sessionfdcheck(). A half-detached opinfo cannot be the owner of an active lease, so returning 0 is the correct match result.

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

f2fs: fix fsck inconsistency caused by incorrect natentry flag usage

f2fsneeddentrymark() reads natentry flags without mutual exclusion with the checkpoint path, which can result in an incorrect inode block marking state. The scenario is as follows:

create & write & fsync 'file A' write checkpoint - f2fsdosyncfile // inline inode - f2fswriteinode // inode folio is dirty - f2fswritecheckpoint - f2fsflushmergedwrites - f2fssyncnodepages - f2fsfsyncnodepages // no dirty node - f2fsneedinodeblockupdate // return true - f2fsfsyncnodepages // inode dirtied - f2fsneeddentrymark //return true - f2fsflushnatentries - f2fswritecheckpoint end - writenodefolio // inode with DENTBITSHIFT set SPO, "fsck --dry-run" find inode has already checkpointed but still with DENTBITSHIFT set

The state observed by f2fsneeddentrymark() can differ from the state observed in writenodefolio() after acquiring sbi->nodewrite. The root cause is that the semantics of ISCHECKPOINTED and HASFSYNCEDINODE are only guaranteed after the checkpoint write has fully completed.

This patch moves setdentrymark() into writenodefolio() and protects it with the sbi->nodewrite lock.

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

netfilter: ebtables: terminate table name before findtablelock()

updatecounters() and compatupdatecounters() forward a user-supplied 32-byte table name to findtablelock() without NUL-terminating it. On a lookup miss, findinlistlock() calls trythenrequestmodule(..., "%s%s", "ebtable", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte.

BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) requestmodule (kernel/module/kmod.c:150) doupdatecounters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) updatecounters (net/bridge/netfilter/ebtables.c:1440) doebtsetctl (net/bridge/netfilter/ebtables.c:2573) nfsetsockopt (net/netfilter/nfsockopt.c:101) ipsetsockopt (net/ipv4/ipsockglue.c:1424) rawsetsockopt (net/ipv4/raw.c:847) syssetsockopt (net/socket.c:2393) ...

compatdoreplace() shares the same unterminated name via compatcopyebtreplacefromuser(); terminate it there too so all findtablelock() callers behave alike. The other callers already terminate the name after the copy.

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

drm/xe/uapi: Reject cohnone PAT index for CPU cached memory in madvise

Add validation in xevmmadviseioctl() to reject PAT indices with XECOHNONE coherency mode when applied to CPU cached memory.

Using cohnone with CPU cached buffers is a security issue. When the kernel clears pages before reallocation, the clear operation stays in CPU cache (dirty). GPU with cohnone can bypass CPU caches and read stale sensitive data directly from DRAM, potentially leaking data from previously freed pages of other processes.

This aligns with the existing validation in vmbind path (xevmbindioctlvalidatebo).

v2(Matthew brost) - Add fixes - Move one debug print to better place

v3(Matthew Auld) - Should be drm/xe/uapi - More Cc

v4(Shuicheng Lin) - Fix kmem leak issues by the way

v5 - Remove kmem leak because it has been merged by another patch

v6 - Remove the fix which is not related to current fix

v7 - No change

v8 - Rebase

v9 - Limit the restrictions to iGPU

v10 - No change

(cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a)

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

usb: typec: class: Fix NULL pointer access

Concurrent calls to typecpartnerunlinkdevice can lead to a NULL pointer dereference. This patch adds a mutex to protect USB device pointers and prevent this issue. The same mutex protects both the device pointers and the partner device registration.

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

nfsd: Initialize ssc before laundromatwork to prevent NULL dereference

In nfs4statestartnet(), laundromatwork may access nfsdssc through nfs4laundromat -> nfsd4sscexpireumount. If nfsdssc isn't initialized, this can cause NULL pointer dereference.

Normally the delayed start of laundromatwork allows sufficient time for nfsdssc initialization to complete. However, when the kernel waits too long for userspace responses (e.g. in nfs4statestartnet -> nfsd4endgrace -> nfsd4recordgracedone -> nfsd4cldgracedone -> cldpipeupcall -> cldpipeupcall -> waitforcompletion path), the delayed work may start before nfsdssc initialization finishes.

Fix this by moving nfsdssc initialization before starting laundromatwork.

ice: fix NULL pointer dereference in iceresetallvfs()

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

slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd

When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards.

One such example can be seen in the following fault, where qcomslimngdssrpdrnotify() schedules work on the NULL ngdupwork.

[ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at queuework+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] queuework+0x5e0/0x790 (P) [ 21.859265] queueworkon+0x6c/0xf0 [ 21.859273] qcomslimngdssrpdrnotify+0x110/0x150 [slimqcomngdctrl] [ 21.859304] qcomslimngdssrnotify+0x24/0x40 [slimqcomngdctrl] [ 21.859318] notifiercallchain+0xa4/0x230 [ 21.859329] srcunotifiercallchain+0x64/0xb8 [ 21.859338] ssrnotifystart+0x40/0x78 [qcomcommon] [ 21.859355] rprocstart+0x130/0x230 [ 21.859367] rprocboot+0x3d4/0x518 ...

Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered.

This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.

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

md: fix mddev uaf while iterating allmddevs list

While iterating allmddevs list from mdnotifyreboot() and mdexit(), listforeachentrysafe is used, and this can race with deletint the next mddev, causing UAF:

t1: spinlock //listforeachentrysafe(mddev, n, ...) mddevget(mddev1) // assume mddev2 is the next entry spinunlock t2: //remove mddev2 ... mddevfree spinlock listdel spinunlock kfree(mddev2) mddevput(mddev1) spinlock //continue dereference mddev2->allmddevs

The old helper foreachmddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex.

Hence switch to use listforeachentry, in this case mddevput() can free the mddev1 and it's not safe as well. Refer to mdseqshow(), also factor out a helper mddevputlocked() to fix this problem.

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

Bluetooth: MGMT: Fix slab-use-after-free Read in mgmtremoveadvmonitorsync

This fixes the following crash:

================================================================== BUG: KASAN: slab-use-after-free in mgmtremoveadvmonitorsync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961

CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 mgmtremoveadvmonitorsync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 hcicmdsyncwork+0x22b/0x400 net/bluetooth/hcisync.c:332 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xa63/0x1850 kernel/workqueue.c:3310 workerthread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK>

Allocated by task 16026: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] kmalloccachenoprof+0x243/0x390 mm/slub.c:4314 kmallocnoprof include/linux/slab.h:901 [inline] kzallocnoprof include/linux/slab.h:1037 [inline] mgmtpendingnew+0x65/0x250 net/bluetooth/mgmtutil.c:269 mgmtpendingadd+0x36/0x120 net/bluetooth/mgmtutil.c:296 removeadvmonitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568 hcimgmtcmd+0xc47/0x11d0 net/bluetooth/hcisock.c:1712 hcisocksendmsg+0x7b8/0x11c0 net/bluetooth/hcisock.c:1832 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x221/0x270 net/socket.c:726 sockwriteiter+0x2d7/0x3f0 net/socket.c:1147 newsyncwrite fs/readwrite.c:586 [inline] vfswrite+0xaeb/0xd30 fs/readwrite.c:679 ksyswrite+0x18f/0x2b0 fs/readwrite.c:731 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 16022: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:582 poisonslabobject mm/kasan/common.c:247 [inline] kasanslabfree+0x59/0x70 mm/kasan/common.c:264 kasanslabfree include/linux/kasan.h:233 [inline] slabfreehook mm/slub.c:2338 [inline] slabfree mm/slub.c:4598 [inline] kfree+0x196/0x420 mm/slub.c:4746 mgmtpendingforeach+0xd1/0x130 net/bluetooth/mgmtutil.c:259 mgmtpoweroff+0x183/0x430 net/bluetooth/mgmt.c:9550 hcidevclosesync+0x6c4/0x11c0 net/bluetooth/hcisync.c:5208 hcidevdoclose net/bluetooth/hcicore.c:483 [inline] hcidevclose+0x112/0x210 net/bluetooth/hcicore.c:508 sockdoioctl+0x158/0x460 net/socket.c:1209 sockioctl+0x626/0x8e0 net/socket.c:1328 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl+0xf5/0x170 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f