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:

cifs: Fix busy dentry used after unmounting

Since commit 340cea84f691c ("cifs: open files should not hold ref on superblock"), cifs file only holds the dentry refcnt, the cifs file close work(cfile->deferred) could be executed after unmounting, which will trigger a warning in genericshutdownsuper: BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of cifs cifs]

The detailed processs is: process A process B kworker fd = open(PATH) vfsopen file->fpath = path // dentry->dlockref.count = 1 cifsopen cifsnewfileinfo cfile->dentry = dget(dentry) // dentry->dlockref.count = 2 close(fd) fput cifsclose queuedelayedwork(deferredclosewq, cfile->deferred) dput(dentry) // dentry->dlockref.count = 1 smb2deferredworkclose cifsFileInfoput listdel(&cifsfile->flist) umount cleanupmnt deactivatesuper cifskillsb cifsclosealldeferredfilessb cifsclosealldeferredfiles // cannot find cfile, skip cifsFileInfoput killanonsuper genericshutdownsuper shrinkdcacheforumount umountcheck WARN ! // dentry->dlockref.count = 1 cifsFileInfoputfinal dput(cifsfile->dentry) // dentry->dlockref.count = 0

Fix it by flushing 'deferredclosewq' before calling killanonsuper.

Fetch a reproducer in https://bugzilla.kernel.org/showbug.cgi?id=221548.

ALSA: PCM: Fix wait queue list corruption in sndpcmdrain() on linked streams

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

openvswitch: vport: fix self-deadlock on release of tunnel ports

vports are used concurrently and protected by RCU, so netdevput() must happen after the RCU grace period. So, either in an RCU call or after the synchronizenet(). The rtnldeletelink() must happen under RTNL and so can't be executed in RCU context. Calling synchronizenet() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdevput() in RCU call is the right solution here.

However, when the device is deleted, rtnlunlock() will call netdevruntodo() and block until all the references are gone. In the current code this means that we never reach the callrcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal.

Fix that by moving the rcucall() before the rtnlunlock(), so the scheduled RCU callback will be executed when synchronizenet() is called from the rtnlunlock()->netdevruntodo() while the RTNL itself is already released.

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

LoongArch: Fix potential ADE in loongsongpufixupdmahang()

The switch case in loongsongpufixupdmahang() may not DC2 or DC3, and readl(crtcreg) will access with random address, because the "device" is from "base+PCIDEVICEID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU:

lspci -tv -[0000:00]-+-00.0 Loongson Technology LLC Hyper Transport Bridge Controller ... +-06.0 Loongson Technology LLC LG100 GPU +-06.2 Loongson Technology LLC Device 7a37 ...

Add a default switch case to fix the panic as below:

Kernel ade access[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4 pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0 a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002 a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001 t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000 t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0 t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8 s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000 s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000 ra: 90000000017e54c0 loongsongpufixupdmahang+0x40/0x210 ERA: 90000000017e5534 loongsongpufixupdmahang+0xb4/0x210 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1) BADV: 7fffffffffffff00 PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval)) Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007 0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff 900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08 0000000000000000 0000000000000000 0000000000000006 90000001002fb778 90000001000530b8 90000000027af000 0000000000000000 9000000100054000 9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001 90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000 0000000000000006 90000000027af000 0000000000000030 90000000027af000 900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560 7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030 ... Call Trace: [<90000000017e5534>] loongsongpufixupdmahang+0xb4/0x210 [<9000000000eebc08>] pcifixupdevice+0x108/0x280 [<9000000000ebb70c>] pcisetupdevice+0x24c/0x690 [<9000000000ebc560>] pciscansingledevice+0xe0/0x140 [<9000000000ebc684>] pciscanslot+0xc4/0x280 [<9000000000ebdd00>] pciscanchildbusextend+0x60/0x3f0 [<9000000000f5bc94>] acpipcirootcreate+0x2b4/0x420 [<90000000017e5e74>] pciacpiscanroot+0x2d4/0x440 [<9000000000f5b02c>] acpipcirootadd+0x21c/0x3a0 [<9000000000f4ee54>] acpibusattach+0x1a4/0x3c0 [<90000000010e200c>] deviceforeachchild+0x6c/0xe0 [<9000000000f4bbf4>] acpidevforeachchild+0x44/0x70 [<9000000000f4ef40>] acpibusattach+0x290/0x3c0 [<90000000010e200c>] deviceforeachchild+0x6c/0xe0 [<9000000000f4bbf4>] acpidevforeachchild+0x44/0x70 [<9000000000f4ef40>] acpibusattach+0x290/0x3c0 [<9000000000f5211c>] acpibusscan+0x6c/0x280 [<900000000189c028>] acpiscaninit+0x194/0x310 [<900000000189bc6c>] acpiinit+0xcc/0x140 [<9000000000220cdc>] dooneinitcall+0x4c/0x310 [<90000000018618fc>] kernelinitfreeable+0x258/0x2d4 [<900000000184326c>] kernelinit+0x28/0x13c [<9000000000222008>] retfromkernelthread+0xc/0xa4

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

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

net: ipa: fix event ring index not programmed for IPA v5.0+

For IPA v5.0+, the event ring index field moved from CHCCNTXT0 to CHCCNTXT1. The v5.0 register definition intended to define this field in the CHCCNTXT1 fmask array but used the old identifier of ERINDEX instead of CHERINDEX.

Without a valid event ring, GSI channels could never signal transfer completions. This caused gsichanneltransquiesce() to block forever in waitforcompletion().

At least for IPA v5.2 this resolves an issue seen where runtime suspend, system suspend, and remoteproc stop all hanged forever. It also meant the IPA data path was completely non functional.

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

ice: ptp: don't WARN when controlling PF is unavailable

In VFIO passthrough setups, it is possible to pass through only a PF which doesn't own the source timer. In that case the PTP controlling PF (adapter->ctrlpf) is never initialized in the VM, so icegetctrlptp() returns NULL and triggers WARNON() in iceptpsetuppf().

Since this is an expected behavior in that configuration, replace WARNON() with an informational message and return -EOPNOTSUPP.

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

mm/hugetlb: restore failed global reservations to subpool

Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resvhugepages caused by incorrectly attributing globally requested pages to the subpool's reservation.

Unfortunately, this fix also introduced the opposite problem, which would leave spool->usedhpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->usedhpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter.

Each failed allocation attempt increments the usedhpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as usedhpages approaches the max limit.

The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepagesubpoolgetpages(spool, 3) succeeds. usedhpages += 3 4.2 hugetlbacctmemory(h, 1) fails: no global pages left usedhpages -= 2 5. Subpool now has usedhpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4.

With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user.

Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages.

The underflow issue that the original commit fixes still remains fixed as well.

Without this fix, usedhpages would keep on leaking if hugetlbacctmemory() fails.

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

drm: Account property blob allocations to memcg

DRMIOCTLMODECREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory.

Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM.

Mark the property blob data allocation with GFPKERNELACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.

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

xfrm: account XFRMAIFID in aevent size calculation

xfrmgetae() allocates the reply skb with xfrmaeventmsgsize(), then buildaevent() appends attributes including XFRMAIFID when x->ifid is set.

xfrmaeventmsgsize() does not include space for XFRMAIFID. For states with ifid, buildaevent() can fail with -EMSGSIZE and hit BUGON(err < 0) in xfrmgetae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMAIFID in the size calculation unconditionally and replace the BUGON with normal error unwinding.

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

wifi: brcmfmac: validate bsscfg indices in IF events

brcmffwehhandleifevent() validates the firmware-provided interface index before it touches drvr->iflist[], but it still uses the raw bsscfgidx field as an array index without a matching range check.

Reject IF events whose bsscfg index does not fit in drvr->iflist[] before indexing the interface array.

[add missing wifi prefix]

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

fs/smb/client: fix out-of-bounds read in cifssanitizeprepath

When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.

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

ipv4: icmp: fix null-ptr-deref in icmpbuildprobe()

ipv6stub->ipv6devfind() may return ERRPTR(-EAFNOSUPPORT) when the IPv6 stack is not active (CONFIGIPV6=m and not loaded), and passing this error pointer to devhold() will cause a kernel crash with null-ptr-deref.

Instead, silently discard the request. RFC 8335 does not appear to define a specific response for the case where an IPv6 interface identifier is syntactically valid but the implementation cannot perform the lookup at runtime, and silently dropping the request may safer than misreporting "No Such Interface".

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

soc: qcom: pd-mapper: Fix element length in servreglocpfrreqei

It looks element length declared in servreglocpfrreqei for reason not matching servreglocpfrreq's reason field due which we could observe decoding error on PD crash.

qmidecodestringelem: String len 81 >= Max Len 65

Fix this by matching with servreglocpfrreq's reason field.

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

ipv6: ioam: fix potential NULL dereferences in ioam6filltracedata()

We need to check in6devget() for possible NULL value, as suggested by Yiming Qian.

Also add skbdstdevrcu() instead of skbdstdev(), and two missing READONCE().

Note that @dev can't be NULL.

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

xsk: validate MTU against usable frame size on bind

AFXDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk.

This becomes a problem since we started to respect tailroom which is subtracted from chunksize (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via netdevice::xdpzcmaxsegs).

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

x86: shadow stacks: proper error handling for mmap lock

김영민 reports that shstkpopsigframe() doesn't check for errors from mmapreadlockkillable(), which is a silly oversight, and also shows that we haven't marked those functions with "mustcheck", which would have immediately caught it.

So let's fix both issues.

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

wifi: wl1251: validate packet IDs before indexing txframes

wl1251txpacketcb() uses the firmware completion ID directly to index the fixed 16-entry wl->txframes[] array. The ID is a raw u8 from the completion block, and the callback does not currently verify that it fits the array before dereferencing it.

Reject completion IDs that fall outside wl->txframes[] and keep the existing NULL check in the same guard. This keeps the fix local to the trust boundary and avoids touching the rest of the completion flow.

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

net: airoha: Fix memory leak in airohaqdmarxprocess()

If an error occurs on the subsequents buffers belonging to the non-linear part of the skb (e.g. due to an error in the payload length reported by the NIC or if we consumed all the available fragments for the skb), the pagepool fragment will not be linked to the skb so it will not return to the pool in the airohaqdmarxprocess() error path. Fix the memory leak partially reverting commit 'd6d2b0e1538d ("net: airoha: Fix page recycling in airohaqdmarxprocess()")' and always running pagepoolputfullpage routine in the airohaqdmarxprocess() error path.

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

drm/vc4: Fix a memory leak in hang state error path

When vc4savehangstate() encounters an early return condition, it returns without freeing the previously allocated kernelstate, leaking memory.

Add the missing kfree() calls by consolidating the early return paths into a single place.

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

bnxten: set backing store type from query type

bnxthwrmfuncbackingstoreqcapsv2() stores resp->type from the firmware response in ctxm->type and later uses that value to index fixed backing-store metadata arrays such as ctxarr[] and bnxtbstoretotrace[].

ctxm->type is fixed by the current backing-store query type and matches the array index of ctx->ctxarr. Set ctxm->type from the current loop variable instead of depending on resp->type.

Also update the loop to advance type from nextvalidtype in the for statement, which keeps the control flow simpler for non-valid and unchanged entries.

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

net/mlx5: Fix switchdev mode rollback in case of failure

If for some internal reason switchdev mode fails, we rollback to legacy mode, before this patch, rollback will unregister the uplink netdev and leave it unregistered causing the below kernel bug.

To fix this, we need to avoid netdev unregister by setting the proper rollback flag 'MLX5PRIVFLAGSSWITCHLEGACY' to indicate legacy mode.

devlink (431) used greatest stack depth: 11048 bytes left mlx5core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), \ necvfs(0), active vports(0) mlx5core 0000:00:03.0: E-Switch: Supported tc chains and prios offload mlx5core 0000:00:03.0: Loading uplink representor for vport 65535 mlx5core 0000:00:03.0: mlx5cmdouterr:816:(pid 456): \ QUERYHCACAP(0x100) opmod(0x0) failed, \ status bad parameter(0x3), syndrome (0x3a3846), err(-22) mlx5core 0000:00:03.0 enp0s3np0 (unregistered): Unloading uplink \ representor for vport 65535 ------------[ cut here ]------------ kernel BUG at net/core/dev.c:12070! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 456 Comm: devlink Not tainted 6.16.0-rc3+ \ #9 PREEMPT(voluntary) RIP: 0010:unregisternetdevicemanynotify+0x123/0xae0 ... Call Trace: [ 90.923094] unregisternetdevicequeue+0xad/0xf0 [ 90.923323] unregisternetdev+0x1c/0x40 [ 90.923522] mlx5evportrepunload+0x61/0xc6 [ 90.923736] eswoffloadsenable+0x8e6/0x920 [ 90.923947] mlx5eswitchenablelocked+0x349/0x430 [ 90.924182] ? ismpsupported+0x57/0xb0 [ 90.924376] mlx5devlinkeswitchmodeset+0x167/0x350 [ 90.924628] devlinknleswitchsetdoit+0x6f/0xf0 [ 90.924862] genlfamilyrcvmsgdoit+0xe8/0x140 [ 90.925088] genlrcvmsg+0x18b/0x290 [ 90.925269] ? pfxdevlinknlpredoit+0x10/0x10 [ 90.925506] ? pfxdevlinknleswitchsetdoit+0x10/0x10 [ 90.925766] ? pfxdevlinknlpostdoit+0x10/0x10 [ 90.926001] ? pfxgenlrcvmsg+0x10/0x10 [ 90.926206] netlinkrcvskb+0x52/0x100 [ 90.926393] genlrcv+0x28/0x40 [ 90.926557] netlinkunicast+0x27d/0x3d0 [ 90.926749] netlinksendmsg+0x1f7/0x430 [ 90.926942] syssendto+0x213/0x220 [ 90.927127] ? sysrecvmsg+0x6a/0xd0 [ 90.927312] x64syssendto+0x24/0x30 [ 90.927504] dosyscall64+0x50/0x1c0 [ 90.927687] entrySYSCALL64afterhwframe+0x76/0x7e [ 90.927929] RIP: 0033:0x7f7d0363e047

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

net: qrtr: replace qrtrtxflow radixtree with xarray to fix memory leak

radixtreecreate() allocates and links intermediate nodes into the tree one by one. If a subsequent allocation fails, the already-linked nodes remain in the tree with no corresponding leaf entry. These orphaned internal nodes are never reclaimed because radixtreeforeachslot() only visits slots containing leaf values.

The radixtree API is deprecated in favor of xarray. As suggested by Matthew Wilcox, migrate qrtrtxflow from radixtree to xarray instead of fixing the radixtree itself [1]. xarray properly handles cleanup of internal nodes — xadestroy() frees all internal xarray nodes when the qrtrnode is released, preventing the leak.

[1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/

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

net: use skbheaderpointer() for TCPv4 GSO fragoff check

Syzbot reported a KMSAN uninit-value warning in gsofeaturescheck() called from netifskbfeatures() [1].

gsofeaturescheck() reads iph->fragoff to decide whether to clear mangleidfeatures. Accessing the IPv4 header via iphdr()/inneriphdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PFPACKET paths.

Use skbheaderpointer() for the TCPv4 fragoff check so the header read is robust whether data is already linear or needs copying.

[1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407

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

nfc: s3fwrn5: allocate rx skb before consuming bytes

s3fwrn82uartread() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recvskb and may already deliver a complete frame before allocating a fresh receive buffer.

If that allocskb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recvskb as NULL for the next receive callback. That breaks the receivebuf() accounting contract and can also lead to a NULL dereference on the next skbputu8().

Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted.

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

NFC: pn533: bound the UART receive buffer

pn532receivebuf() appends every incoming byte to dev->recvskb and only resets the buffer after pn532uartrxisframe() recognizes a complete frame. A continuous stream of bytes without a valid PN532 frame header therefore keeps growing the skb until skbputu8() hits the tail limit.

Drop the accumulated partial frame once the fixed receive buffer is full so malformed UART traffic cannot grow the skb past PN532UARTSKBBUFFLEN.

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

Bluetooth: hcisync: Fix UAF in lereadfeaturescomplete

This fixes the following backtrace caused by hciconn being freed before lereadfeaturescomplete but after hcilereadremotefeaturessync so hciconndel -> hcicmdsyncdequeue is not able to prevent it:

================================================================== BUG: KASAN: slab-use-after-free in instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] BUG: KASAN: slab-use-after-free in atomicdecandtest include/linux/atomic/atomic-instrumented.h:1383 [inline] BUG: KASAN: slab-use-after-free in hciconndrop include/net/bluetooth/hcicore.h:1688 [inline] BUG: KASAN: slab-use-after-free in lereadfeaturescomplete+0x5b/0x340 net/bluetooth/hcisync.c:7344 Write of size 4 at addr ffff8880796b0010 by task kworker/u9:0/52

CPU: 0 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:194 [inline] kasancheckrange+0x100/0x1b0 mm/kasan/generic.c:200 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicdecandtest include/linux/atomic/atomic-instrumented.h:1383 [inline] hciconndrop include/net/bluetooth/hcicore.h:1688 [inline] lereadfeaturescomplete+0x5b/0x340 net/bluetooth/hcisync.c:7344 hcicmdsyncwork+0x1ff/0x430 net/bluetooth/hcisync.c:334 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3421 kthread+0x3c5/0x780 kernel/kthread.c:463 retfromfork+0x983/0xb10 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK>

Allocated by task 5932: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:400 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:417 kmallocnoprof include/linux/slab.h:957 [inline] kzallocnoprof include/linux/slab.h:1094 [inline] hciconnadd+0xf8/0x1c70 net/bluetooth/hciconn.c:963 hciconnaddunset+0x76/0x100 net/bluetooth/hciconn.c:1084 leconncompleteevt+0x639/0x1f20 net/bluetooth/hcievent.c:5714 hcileenhconncompleteevt+0x23d/0x380 net/bluetooth/hcievent.c:5861 hcilemetaevt+0x357/0x5e0 net/bluetooth/hcievent.c:7408 hcieventfunc net/bluetooth/hcievent.c:7716 [inline] hcieventpacket+0x685/0x11c0 net/bluetooth/hcievent.c:7773 hcirxwork+0x2c9/0xeb0 net/bluetooth/hcicore.c:4076 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3421 kthread+0x3c5/0x780 kernel/kthread.c:463 retfromfork+0x983/0xb10 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246

Freed by task 5932: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:587 kasansavefreeinfo mm/kasan/kasan.h:406 [inline] poisonslabobject mm/kasan/common.c:252 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfree mm/slub.c:6663 [inline] kfree+0x2f8/0x6e0 mm/slub.c:6871 devicerelease+0xa4/0x240 drivers/base/core.c:2565 kobjectcleanup lib/kobject.c:689 [inline] kobjectrelease lib/kobject.c:720 [inline] krefput include/linux/kref.h:65 [inline] kobjectput+0x1e7/0x590 lib/kobject. ---truncated---

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

USB: dummy-hcd: Fix locking/synchronization error

Syzbot testing was able to provoke an addressing exception and crash in the usbgadgetudcreset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second ("driver") argument of NULL. The bad caller was setlinkstate() in dummyhcd.c, and the problem arose because of a race between a USB reset and driver unbind.

These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first.

The error responsible for the syzbot crash occurred because the stopactivity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stopactivity() occurs in setlinkstate() when handling an emulated USB reset, after the test of dum->intsenabled and before the increment of dum->callbackusage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->intsenabled and dum->driver. Normally this other thread would have to wait for dum->callbackusage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callbackusage had not yet been incremented.

The fix is to increment dum->callbackusage before calling stopactivity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usbgadgetudcreset() safely returns and dum->callbackusage has been decremented again.

drm/amdgpu: fix sync handling in amdgpudmabufmovenotify