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

netfs: Fix overrun check in netfsextractuseriter()

Fix netfsextractuseriter() so that if ioviterextractpages() overfills pages[], then those pages don't get included in the iterator constructed at the end of the function. If there was an overfill, memory corruption has already happened.

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

locking/rtmutex: Skip removewaiter() when waiter is not enqueued

syzbot triggered the following splat in removewaiter() via FUTEXCMPREQUEUEPI:

KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] classrawspinlockconstructor removewaiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rtmutexstartproxylock+0x103/0x120 futexrequeue+0x10e4/0x20d0 x64sysfutex+0x34f/0x4d0

taskblocksonrtmutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in removewaiter()") made this fatal.

Furthermore, rtmutexstartproxylock() should not be calling into removewaiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the removewaiter() out of rtmutexstartproxylock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for trytotakertmutex().

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

ipv6: fix possible infinite loop in fib6selectpath()

Found while auditing the same pattern Sashiko reported in rt6fillnode() [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6infousesdev()").

Writers holding tb6lock can listdelrcu(&first->fib6siblings) without waiting for RCU readers; first->fib6siblings.next then still points into the old ring and this softirq-side walker never reaches &first->fib6siblings as its terminator. fib6purgert() always WRITEONCE()s first->fib6nsiblings to 0 before listdelrcu(), so an inside-loop check is a reliable detach signal.

[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev

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

arm64: Reserve an extra page for early kernel mapping

The final part of [data, end) segment may overflow into the next page of initpgend[1] which is the gap page before earlyinitstack[2]:

[1] crasharm64v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000

PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000

PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved

[2] ffffffed002c8000 (r) pidata ffffffed0054e000 (d) pibssstart ffffffed005f5000 (b) piinitpgdir ffffffed005fe000 (b) piinitpgend ffffffed005ff000 (B) earlyinitstack ffffffed00608000 (b) piend

For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary.

KERNELSEGMENTCOUNT still correctly counts the five permanent kernel VMAs registered by declarekernelvmas(). However, since commit 5973a62efa34 ("arm64: map [text, stext) virtual address range non-executable+read-only"), the early mapper also maps [text, stext) separately from [stext, etext). This adds one more early-only split and can require one more page-table page than the existing EARLYSEGMENTEXTRAPAGES allowance reserves.

Increase the 4K-page early mapping allowance by one page to cover that additional split.

[catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment]

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

smb/client: fix out-of-bounds read in smb2compoundop()

If a server sends a truncated response but a large OutputBufferLength, and terminates the EA list early, checkwsleas() returns success without validating that the entire OutputBufferLength fits within iovlen.

Then smb2compoundop() does: memcpy(idata->wsl.eas, data[0], size[0]);

Where size[0] is OutputBufferLength. If iovlen is smaller than size[0], memcpy can read beyond the end of the rspiov allocation and leak adjacent kernel heap memory.

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

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmettcphandleicreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before iowork drains the already buffered ICReq. In that case, nvmettcpschedulereleasequeue() sets queue->state to NVMETTCPQDISCONNECTING and drops the queue reference under statelock.

If iowork later processes that ICReq, nvmettcphandleicreq() can still overwrite the state back to NVMETTCPQLIVE. That defeats the DISCONNECTING-state guard in nvmettcpschedulereleasequeue() and allows a later socket state change to re-enter teardown and issue a second krefput() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMETTCPQFAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with statelock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmettcpsocketerror() setting rcvstate to NVMETTCPRECVERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.

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

Bluetooth: bnep: Fix UAF read of dev->name

bnepaddconnection() needs to keep holding the bnepsessionsem while reading dev->name (just like bnepgetconnlist() does); otherwise the bnepsession() thread can concurrently free the netdevice, which can for example be triggered by a concurrent bnepdelconnection().

(This UAF is fairly uninteresting from a security perspective; calling bnepaddconnection() requires passing a capable(CAPNETADMIN) check. It also requires completely tearing down a netdev during a fairly tight race window.)

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

net: wwan: iosm: fix potential memory leaks in ipcimeminit()

The memory allocated in ipcprotocolinit() is not freed on the error paths that follow in ipcimeminit(). Fix that by calling the corresponding release function ipcprotocoldeinit() in the error path.

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

drm/amd/display: Validate payload length and linkindex in dcprocessdmubauxtransferasync

[Why&How] dcprocessdmubauxtransferasync() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy.

Additionally, linkindex is used to dereference dc->links[] without bounds checking against dc->linkcount, risking an out-of-bounds access.

Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for linkindex before it is used.

(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)

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

device property: set fwnode->secondary to NULL in fwnodeinit()

If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnodeinit(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor ISERR() and so may end up being dereferenced (for example: in devtoswnode()). Set fwnode->secondary to NULL on initialization.

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

spi: ti-qspi: fix use-after-free after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to clear the DMA channel pointer also if buffer allocation fails to avoid passing a pointer to the released channel to the DMA engine (or trying to free the channel a second time on late probe errors or driver unbind).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

usb: gadget: net2280: Fix double free in probe error path

usbinitializegadget() installs gadgetrelease() as the release callback for the embedded gadget device. The struct net2280 instance is therefore released through gadgetrelease() when the gadget device's last reference is dropped.

The probe error path calls net2280remove(), which tears down the partially initialized device and drops the gadget reference with usbputgadget(). Calling kfree(dev) afterwards can free the same object again.

Drop the explicit kfree() and let the gadget device release callback handle the final free. This issue was found by a static analysis tool I am developing.

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

ASoC: codecs: simple-mux: Fix enum control bounds check

simplemuxcontrolput() rejects values greater than e->items, but enum control values are zero based. For the two-entry mux used by this driver, valid values are 0 and 1, so value 2 must be rejected as well.

Accepting e->items can store an invalid mux state, pass it to the GPIO setter, and pass it on to the DAPM mux update path where it is used as an index into the enum text array.

Use the same >= e->items check used by the ASoC enum helpers.

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

batman-adv: tt: fix negative ttbufflen

batadvorignode::ttbufflen was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.

In batadvsendotherttresponse(), ttbufflen is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadvttpreparetvlvglobaldata() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.

Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadvsendotherttresponse().

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

ipv4: raw: reject IPHDRINCL packets with ihl < 5

rawsendhdrinc() validates that the caller-supplied IPv4 header fits within the message length:

iphlen = iph->ihl 4; err = -EINVAL; if (iphlen > length) goto errorfree;

if (iphlen >= sizeof(iph)) { / fix up saddr, totlen, id, csum, transportheader / }

It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to iplocalout() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ahoutput() in particular subtracts sizeof(struct iphdr) from topiph->ihl 4 and passes the (signed-int-negative, then cast to sizet) result to memcpy(), producing an OOB access of length close to SIZEMAX and a host kernel panic.

An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path.

Reject "iphlen < sizeof(iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to.

Once this lands, the "if (iphlen >= sizeof(iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it.

Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl.

Reachability: the malformed packet source is any caller with CAPNETRAW, including an unprivileged process in a user+net namespace on a kernel with CONFIGUSERNS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAPNETADMIN can install that state and policy in its netns. Loopback bypasses xfrmoutput, so the trigger uses a real netdev.

Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpyorig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NETADMIN on a stock distro kernel.

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

ixgbevf: fix use-after-free in VEPA multicast source pruning

ixgbevfcleanrxirq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:

devkfreeskbirq(skb); continue;

The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevfaddrxfrag() on the freed skb, dereferencing skbshinfo(skb)->nrfrags - a use-after-free in NAPI softirq context.

The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.

I do not have ixgbevf hardware; the bug was found by static analysis (scandropcontinueloops.py + semgrep dropcontinueinloop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfreeskb, then read skbshinfo(skb)->nrfrags):

BUG: KASAN: slab-use-after-free in ixgbevfuaftestinit+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)

QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.

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

tracing: Do not call map->ops->eltfree() if eltalloc() fails

In paths where tracingmapeltalloc() failed to allocate objects, the map->ops->eltalloc() call was never successful. In this case, map->ops->eltfree() should not be called.

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

kho: skip KHO for crash kernel

khofillkimage() unconditionally populates the kimage with KHO metadata for every kexec image type. When the image is a crash kernel, this can be problematic as the crash kernel can run in a small reserved region and the KHO scratch areas can sit outside it. The crash kernel then faults during khomemoryinit() when it tries phystovirt() on the KHO FDT address:

Unable to handle kernel paging request at virtual address xxxxxxxx ... fdtoffsetptr+... fdtchecknodeoffset+... fdtfirstpropertyoffset+... fdtgetpropertynamelen+... fdtgetprop+... khomemoryinit+... mmcoreinit+... startkernel+...

kholocatememhole() already skips KHO logic for KEXECTYPECRASH images, but khofillkimage() was missing the same guard. As khofillkimage() is the single point that populates image->kho.fdt and image->kho.scratch, fixing it here is sufficient for both arm64 and x86 as the FDT and bootparams path are bailing out when these fields are unset.

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

idpf: fix readdevclklock spinlock init in idpfptpinit()

In idpfptpinit(), readdevclklock is initialized after ptpscheduleworker() had already been called (and after idpfptpsettime64() could reach the lock). The PTP aux worker fires immediately upon scheduling and can call into idpfptpreadsrcclkregdirect(), which takes spinlock(&ptp->readdevclklock) on an uninitialized lock, triggering the lockdep "non-static key" warning:

[12973.796587] idpf 0000:83:00.0: Device HW Reset initiated [12974.094507] INFO: trying to register non-static key. ... [12974.097208] Call Trace: [12974.097213] <TASK> [12974.097218] dumpstacklvl+0x93/0xe0 [12974.097234] registerlockclass+0x4c4/0x4e0 [12974.097249] ? lockacquire+0x427/0x2290 [12974.097259] lockacquire+0x98/0x2290 [12974.097272] lockacquire+0xc6/0x310 [12974.097281] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097311] ? lockdephardirqsonprepare+0xde/0x190 [12974.097318] ? finishtaskswitch.isra.0+0xd2/0x350 [12974.097330] ? pfxptpauxkworker+0x10/0x10 [ptp] [12974.097343] rawspinlock+0x30/0x40 [12974.097353] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097373] idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097391] ? kthreadworkerfn+0x88/0x3d0 [12974.097404] ? kthreadworkerfn+0x4e/0x3d0 [12974.097411] idpfptpupdatecachedphctime+0x26/0x120 [idpf] [12974.097428] ? rawspinunlockirq+0x28/0x50 [12974.097436] idpfptpdoauxwork+0x15/0x20 [idpf] [12974.097454] ptpauxkworker+0x20/0x40 [ptp] [12974.097464] kthreadworkerfn+0xd5/0x3d0 [12974.097474] ? pfxkthreadworkerfn+0x10/0x10 [12974.097482] kthread+0xf4/0x130 [12974.097489] ? pfxkthread+0x10/0x10 [12974.097498] retfromfork+0x32c/0x410 [12974.097512] ? pfxkthread+0x10/0x10 [12974.097519] retfromforkasm+0x1a/0x30 [12974.097540] </TASK>

Move the call to spinlockinit() up a bit to make sure readdevclklock is not touched before it's been initialized.

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

ALSA: asihpi: Fix potential OOB array access at reading cache

findcontrol() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it.

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

mm: fix vmnormalpage() to handle missing support for pmdspecial()/pudspecial()

On x86 32-bit with THP enabled, zaphugepmd() is seen to generate a "WARNING: mm/memory.c:735 at vmnormalpage+0x6a/0x7d", from the VMWARNONONCE(iszeropfn(pfn) || ishugezeropfn(pfn)); followed by "BUG: Bad rss-counter state"s, then later "BUG: Bad page state"s when reclaim gets to call shrinkhugezerofolioscan().

It's as if the PAGESPECIAL bit never got set in the hugezero pmd: and indeed, whereas ptespecial() and ptemkspecial() are subject to a dedicated CONFIGARCHHASPTESPECIAL, pmdspecial() and pmdmkspecial() are subject to CONFIGARCHSUPPORTSPMDPFNMAP, which is never enabled on any 32-bit architecture.

While the problem was exposed through commit d80a9cb1a64a ("mm/hugememory: add and use normalorsoftleaffoliopmd()"), it was an oversight in commit af38538801c6 ("mm/memory: factor out common code from vmnormalpage()") and would result in other problems: huge zero folio accounted in smaps, pagemap (PAGEISFILE) and numamaps as file-backed THP foliowalkstart() returning the folio even without FWZEROPAGE set. Callers seem to tolerate that, though.

... and triggering the VMWARNONONE(), although never reported so far.

To fix it, teach vmnormalpagepmd()/vmnormalpagepud() to consider whether pmdspecial/pudspecial is actually implemented.

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

btrfs: tracepoints: fix sleep while in atomic context in btrfssyncfile()

The trace event btrfssyncfile() is called in an atomic context (all trace events are) and its call to dput(), which is needed due to the call to dgetparent(), can sleep, triggering a kernel splat.

This can be reproduced by enabling the trace event and running btrfs/056 from fstests for example. The splat shown in dmesg is the following:

[53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970 [53.947] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 32773, name: xfsio [53.988] preemptcount: 2, expected: 0 [53.967] RCU nest depth: 0, expected: 0 [53.943] Preemption disabled at: [53.944] [<0000000000000000>] 0x0 [54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfsio Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full) [54.070] Tainted: [W]=WARN [54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] Call Trace: [54.074] <TASK> [54.076] dumpstacklvl+0x56/0x80 [54.079] mightresched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] traceeventraweventbtrfssyncfile+0x75/0x140 [btrfs] [54.089] btrfssyncfile+0x1ed/0x530 [btrfs] [54.087] ? handlemmfault+0x8ae/0xed0 [54.089] btrfsdowriteiter+0x172/0x210 [btrfs] [54.091] vfswrite+0x21f/0x450 [54.094] x64syspwrite64+0x8d/0xc0 [54.096] ? douseraddrfault+0x20c/0x670 [54.099] dosyscall64+0x60/0xf20 [54.092] ? clearbhbloop+0x60/0xb0 [54.094] entrySYSCALL64afterhwframe+0x76/0x7e

So stop using dgetparent() and dput() and access the parent dentry directly as dentry->dparent. This is also what ext4 is doing in its equivalent trace event ext4syncfileenter().

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

spi: sprd: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

spi: qup: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

mm/damon/sysfs-schemes: call missing memcgroupiterbreak()

damonsysfsmemcgpathtoid() breaks memcgroupiter() loop without calling memcgroupiterbreak(). This leaks the cgroup reference. Fix the issue by calling memcgroupiterbreak() before the break.

The issue was discovered [1] by Sashiko.

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

efi: Allocate runtime workqueue before ACPI init

Since commit

5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")

ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware.

Rafael reports that such PRM accesses may occur before efisubsysinit() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpiinit() [which triggers the early PRM accesses] executes as a subsysinitcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpiinit() is not an option.

So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsysinitcall() level.

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

iommu/amd: Remove latent out-of-bounds access in IOMMU debugfs

In iommummiowrite() and iommucapabilitywrite(), the variables dbgmmiooffset and dbgcapoffset are declared as int. However, they are populated using kstrtou32fromuser(). If a user provides a sufficiently large value, it can become a negative integer.

Prior to this patch, the AMD IOMMU debugfs implementation was already protected by different mechanisms.

1. #define OFSINSZ 8 ensures the user string <= 8 bytes, so e.g. 0xffffffff isn't a valid input.

if (cnt > OFSINSZ) return -EINVAL;

2. Implicit type promotion in iommummiowrite(), dbgmmiooffset is int and iommu->mmiophysend is u64

if (dbgmmiooffset > iommu->mmiophysend - sizeof(u64)) return -EINVAL;

3. The show handlers would currently catch the negative number and refuse to perform the read.

Replace kstrtou32fromuser() with kstrtos32fromuser() to parse the input, and check for negative values to explicitly prevent out-of-bounds memory accesses directly in iommummiowrite() and iommucapabilitywrite().

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

batman-adv: bla: fix reportwork leak on backbonegw purge

batadvblapurgebackbonegw() removes stale backbone gateway entries, but fails to properly handle their associated reportwork:

- If reportwork is running, the purge must wait for it to finish before freeing the backbonegw, otherwise the worker may access freed memory (e.g. batpriv). - If reportwork is pending, the purge must cancel it and release the reference held for that pending work item.

The previous implementation called hlistforeachentrysafe() inside a spinlockbh() section, but cancelworksync() may sleep and therefore cannot be called from within a spinlock-protected region.

Restructure the loop to handle one entry per spinlock critical section: acquire the lock, find the next entry to purge, remove it from the hash list, then release the lock before calling cancelworksync() and dropping the hashentry reference. Repeat until no more entries require purging.

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

phy: qcom: qmp-usbc: Fix out-of-bounds array access in dp swing config

swingtbl and preemphasistbl are 4x4 arrays (valid indices 0-3), but the boundary check uses "> 4" instead of ">= 4", allowing index 4 to cause an out-of-bounds access.

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

media: rc: igorplugusb: fix control request setup packet

Commit eac69475b01f ("media: rc: igorplugusb: heed coherency rules") changed the control request storage from an embedded struct to an allocated pointer so it can obey DMA coherency rules.

However, the driver still passes &ir->request to usbfillcontrolurb(). That points the URB setup packet at the pointer field itself rather than at the allocated struct usbctrlrequest.

USB core then interprets pointer bytes as the setup packet. This can produce an invalid bRequestType and trigger the control direction warning reported by syzbot:

usb 2-1: BOGUS control dir, pipe 80003580 doesn't match bRequestType 0

Pass ir->request itself as the setup packet.