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:

dm log: fix out-of-bounds write due to regioncount overflow

The local variable regioncount in createlogcontext() is declared as unsigned int (32-bit), but dmsectordivup() returns sectort (64-bit). When a device-mapper target has a sufficiently large ti->len with a small regionsize, the division result can exceed UINTMAX. The truncated value is then used to calculate bitsetsize, causing cleanbits, syncbits, and recoveringbits to be allocated far smaller than needed for the actual number of regions.

Subsequent log operations (logsetbit, logclearbit, logtestbit) use region indices derived from the full untruncated region space, causing out-of-bounds writes to kernel heap memory allocated by vmalloc.

This can be reproduced by creating a mirror target whose regioncount overflows 32 bits:

dmsetup create bigzero --table '0 8589934594 zero' dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \ /dev/mapper/bigzero 0'

The status output confirms the truncation (synccount=1 instead of 4294967297, because 0x100000001 was truncated to 1):

$ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1 1/4294967297 ...

This leads to a kernel crash in coreinsync:

BUG: scheduling while atomic: (udev-worker)/9150/0x00000000 RIP: 0010:coreinsync+0x14/0x30 [dmlog] CR2: 0000000000000008 Fixing recursive fault but reboot is needed!

Fix by widening the local regioncount to sectort and adding an explicit overflow check before the value is assigned to lc->regioncount.

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:

wifi: libertastf: fix use-after-free in lbtffreeadapter()

lbtffreeadapter() calls timerdelete(&priv->commandtimer), which does not wait for a running commandtimerfn() callback. lbtffreeadapter() runs on the teardown path right before ieee80211freehw() frees priv, both in lbtfremovecard() and in the probe error path. commandtimer is armed by modtimer() in lbtfcmd() whenever a firmware command is sent. commandtimerfn() dereferences priv. If a command times out as the device is removed, commandtimerfn() runs concurrently with teardown and dereferences priv after it has been freed.

This is the same use-after-free that commit 03cc8f90d053 ("wifi: libertas: fix use-after-free in lbsfreeadapter()") fixed in the sibling libertas driver. The libertastf variant has the identical pattern and was left unchanged. Use timerdeletesync() so any in-flight callback completes before priv is freed.

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

crypto: authencesn - reject short ahash digests during instance creation

authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data.

While cryptoauthencesnsetauthsize() already rejects explicit non-zero authsizes in the range 1..3, cryptoauthencesncreate() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value.

As a result, selecting an ahash with digest size 1..3, such as cbcmac(ciphernull), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AFALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access.

Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.

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:

crypto: atmel-sha204a - fix blocking and non-blocking rng logic

The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message.

Tested on an Atmel SHA204A device.

Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020

After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020

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:

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:

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.

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).

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

perf/x86/amd/core: Avoid enabling BRS from the SVM reload path

Branch Sampling (BRS) and Last Branch Record (LBR) are mutually exclusive hardware features, and users of both are tracked via cpuc->lbrusers.

When SVM is toggled on a CPU, the host perf events are reprogrammed to update the HostOnly filter bit (set when virtualization is enabled, cleared when it is disabled). On PerfMonV2-capable processors, this reprogramming is performed by calling amdpmuenableall() to rewrite the event selectors. However, amdpmuenableall() also calls amdbrsenableall(), which enables BRS whenever cpuc->lbrusers > 0. Having active LBR events satisfies this gating on processors that have LBR but not BRS. The kernel then tries to set the BRS enable bit in DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such hardware, the write results in a #GP:

Call Trace: <IRQ> amdpmuenableall+0x1d/0x90 amdpmudisablevirt+0x62/0xb0 kvmarchdisablevirtualizationcpu+0xa/0x40 [kvm] hardwaredisablenolock+0x1a/0x30 [kvm] flushsmpcallfunctionqueue+0x9b/0x410 sysveccallfunction+0x18/0xc0 sysveccallfunction+0x69/0x90 </IRQ> <TASK> asmsysveccallfunction+0x16/0x20 RIP: 0010:cpuidleenterstate+0xc4/0x450 ? cpuidleenterstate+0xb7/0x450 cpuidleenter+0x29/0x40 cpuidleidlecall+0xf5/0x160 doidle+0x7b/0xe0 cpustartupentry+0x26/0x30 startsecondary+0x115/0x140 secondarystartup64noverify+0x194/0x19b </TASK>

Fix this by ensuring that BRS is not enabled from the event selector reprogramming path even when cpuc->lbrusers > 0.

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

gpio: mvebu: free generic chips on unbind

irqallocdomaingenericchips() allocates generic chip data that must be freed via irqdomainremovegenericchips(). The devres action mvebugpioremoveirqdomain() only called irqdomainremove(), which only frees the generic chips if IRQDOMAINFLAGDESTROYGC is set. Call irqdomainremovegenericchips() explicitly before irqdomainremove() instead.

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

batman-adv: frag: free unfragmentable packet

The caller of batadvfragsendpacket() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions.

A failed pre-check must use the same error handling code as the rest of the function.

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

mm/damon/core: always put unsuccessfully committed target pids

damoncommittarget() puts and gets the destination and the source target pids. It puts the destination target pid because it will be overwritten by the source target pid. It gets the source pid because the caller is supposed to eventually put the pids. In more detail, the caller will call damondestroyctx() after damoncommitctx() to destroy the entire source context. And in this case, [f]vaddr operation set's cleanuptarget() callback will put the pids.

The commit operation is made at the context level. The operation can fail in multiple places including in the middle and after the targets commit operations. For any such failures, immediately the error is returned to the damoncommitctx() caller. If some or all of the source target pids were committed to the destination during the unsuccessful context commit attempt, those pids should be put twice.

The source context will do the put operations using the above explained routine. However, let's suppose the destination context was not originally using [f]vaddr operation set and the commit failed before the ops of the source context is committed. The destination does not have the cleanuptarget() ops callback, so it cannot put the pids via the damondestroyctx().

As a result, the pids are leaked. The issue in the real world would be not very common. The commit feature is for changing parameters of running DAMON context while inheriting internal status like the monitoring results. The monitoring results of a physical address range ain't have things that are beneficial to be inherited to a virtual address ranges monitoring. So the problem-causing DAMON control would be not very common in the real world. That said, it is a supported feature. And damoncommittarget() failure due to memory allocation is relatively realistic [1] if there are a huge number of target regions.

Fix by putting the pids in the commit operation in case of the failures.

The issue was discovered [2] by Sashiko.

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

smp: Make CSD lock acquisition atomic for debug mode

Commit b0473dcd4b1d ("smp: Improve smpcallfunctionsingle() CSD-lock diagnostics") changed smpcallfunctionsingle() so that, when CSD lock debugging is enabled, async !wait calls use the destination CPU csddata. That improves diagnostics, but it also removes the single-writer property that made the old csdlock() safe: multiple CPUs can now prepare the same destination CPU CSD concurrently.

csdlock() currently waits for CSDFLAGLOCK to clear and then sets the bit with a non-atomic read-modify-write. Two senders can both see an unlocked CSD, set the bit, overwrite the callback fields, and enqueue the same llist node. Re-adding a node that is already the queue head can make node->next point to itself, leaving the target CPU stuck walking callsinglequeue. Later synchronous work, such as a TLB shootdown, can then remain queued and trigger soft-lockup warnings or panics.

Keep the single csdlock() implementation, but when CSD lock debugging is enabled, acquire CSDFLAGLOCK with trycmpxchgacquire(). This makes the destination CPU CSD a real atomic lock in the only configuration where it can be shared by multiple remote senders, while preserving the existing non-debug fast path.

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:

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:

HID: hid-lenovo-go: cancel cfgsetup work in hidgocfgremove()

hidgocfgprobe() initialises drvdata.gocfgsetup and schedules it to run 2 ms later:

INITDELAYEDWORK(&drvdata.gocfgsetup, &cfgsetup); scheduledelayedwork(&drvdata.gocfgsetup, msecstojiffies(2));

cfgsetup() dereferences drvdata.hdev to issue MCU command requests. hidgocfgremove() tears down sysfs and stops the HID device, but never drains the delayed work. If the device is unbound within the 2 ms scheduling delay (a probe failure rolling back via remove, or a fast rmmod after probe), the work fires after hiddestroydevice() has dropped its reference and released the underlying hdev struct, leaving cfgsetup() with a stale drvdata.hdev pointer.

Mirror the sibling driver hid-lenovo-go-s.c, whose hidgoscfgremove() already calls canceldelayedworksync() on its analogous work, and drain gocfgsetup at the top of hidgocfgremove(). The cancel must come before guard(mutex)(&drvdata.cfgmutex) because cfgsetup() acquires that mutex; reversing the order would deadlock.

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.

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

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

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:

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:

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:

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:

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:

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:

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:

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.