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:

gpio: shared: fix deadlock on shared proxy's parent removal

Commit 710abda58055 ("gpio: shared: call gpiochip::ofxlate() if set") used the mutex embedded in struct gpiosharedentry to protect the offset field which now can be modified after assignment. The critical section however is too wide and introduced a potential deadlock on the removal of the shared GPIO proxy's parent.

Make the critical section shorter - only protect the offset when it's being read.

While at it: mention the fact that the entry lock is now also used to protect against concurrent access to the offset field in the structure's documentation.

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:

cgroup: Defer css percpuref kill on rmdir until cgroup is depopulated

A chain of commits going back to v7.0 reworked rmdir to satisfy the controller invariant that a subsystem's ->cssoffline() must not run while tasks are still doing kernel-side work in the cgroup.

[1] d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out") [2] a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup") [3] 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir") [4] 4c56a8ac6869 ("cgroup: Fix cgroupdraindying() testing the wrong condition") [5] 13e786b64bd3 ("cgroup: Increment nrdyingsubsys from rmdir context")

[1] moved task cset unlink from doexit() to finishtaskswitch() so a task's cset link drops only after the task has fully stopped scheduling. That made tasks past exitsignals() linger on cset->tasks until their final context switch, which led to a series of problems as what userspace expected to see after rmdir diverged from what the kernel needs to wait for. [2]-[5] tried to bridge that divergence: [2] filtered the exiting tasks from cgroup.procs; [3] had rmdir(2) sleep in TASKUNINTERRUPTIBLE for them; [4] fixed the wait's condition; [5] made nrdyingsubsys visible synchronously.

The cgroupdraindying() wait in [3] turned out to be a dead end. When the rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g. host PID 1 systemd reaping orphan pids that were re-parented to it during the same teardown), rmdir blocks in TASKUNINTERRUPTIBLE waiting for those pids to free, the pids can't free because PID 1 is the reaper and it's stuck in rmdir, and the system A-A deadlocks. No internal lock ordering breaks this; the wait itself is the bug.

The css killing side that drove the original reorder, however, can be made cleanly asynchronous: ->cssoffline() is already async, run from csskilledworkfn() driven by percpurefkillandconfirm(). The fix is to make that chain start only after all tasks have left the cgroup. rmdir's user-visible side then returns as soon as cgroup.procs and friends are empty, while ->cssoffline() still runs only after the cgroup is fully drained.

Verified by the original reproducer (pidns teardown + zombie reaper, runs under vng) which hangs vanilla and succeeds here, and by per-commit deterministic repros for [2], [3], [4], [5] with a boot parameter that widens the post-exitsignals() window so each state is reliably reachable. Some stress tests on top of that.

cgroupapplycontroldisable() has the same shape of pre-existing race: when a controller is disabled via subtreecontrol, killcss() ran synchronously while tasks past exitsignals() could still be linked to the cgroup's csets, and ->cssoffline() could fire before they drained. This patch preserves the existing synchronous behavior at that call site (killcsssync() + killcssfinish() back-to-back) and a follow-up patch will defer killcssfinish() there using a per-css trigger.

This seems like the right approach and I don't see problems with it. The changes are somewhat invasive but not excessively so, so backporting to -stable should be okay. If something does turn out to be wrong, the fallback is to revert the entire chain ([1]-[5]) and rework in the development branch instead.

v2: Pin cgrp across the deferred destroy work with explicit cgroupget()/cgroupput() around queuework() and the workfn. v1 wasn't actually broken (ordered cgroupofflinewq + queuework order in cgrouptaskdead() saved it) but the explicit ref removes the dependency on those non-obvious invariants. Also note the pre-existing cgroupapplycontroldisable() race in the description; a follow-up will defer killcssfinish() there.

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

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

usb: ulpi: fix memory leak on ulpiregister() error paths

Commit 01af542392b5 ("usb: ulpi: fix double free in ulpiregisterinterface() error path") removed kfree(ulpi) from ulpiregisterinterface() to fix a double-free when deviceregister() fails.

But when ulpiofregister() or ulpireadid() fail before deviceregister() is called, the ulpi allocation is leaked.

Add kfree(ulpi) on both error paths to properly clean up the allocation.

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:

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:

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:

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:

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

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

USB: dummy-hcd: Fix interrupt synchronization error

This fixes an error in synchronization in the dummy-hcd driver. The error has a somewhat involved history. The synchronization mechanism was introduced by commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), which added an emulated "interrupts enabled" flag together with code emulating synchronizeirq() (it waits until all current handler callbacks have returned).

But the emulated interrupt-disable occurred too late, after the driver containing the handler callback routines had been told that it was unbound and no more callbacks would occur. Commit 4a5d797a9f9c ("usb: gadget: dummyhcd: fix gpf in gadgetsetup") tried to fix this by moving the synchronizeirq() emulation code from dummystop() to dummypullup(), which runs before the unbind callback.

There still were races, though, because the emulated interrupt-disable still occurred too late. It couldn't be moved to dummypullup(), because that routine can be called for reasons other than an impending unbind. Therefore commits 7dc0c55e9f30 ("USB: UDC core: Add udcasynccallbacks gadget op") and 04145a03db9d ("USB: UDC: Implement udcasynccallbacks in dummy-hcd") added an API allowing the UDC core to tell dummy-hcd exactly when emulated interrupts and their callbacks should be disabled.

That brings us to the current state of things, which is still wrong because the emulated synchronizeirq() occurs before the emulated interrupt-disable! That's no good, beause it means that more emulated interrupts can occur after the synchronizeirq() emulation has run, leading to the possibility that a callback handler may be running when the gadget driver is unbound.

To fix this, we have to move the synchronizeirq() emulation code yet again, to the dummyudcasynccallbacks() routine, which takes care of enabling and disabling emulated interrupt requests. The synchronization will now run immediately after emulated interrupts are disabled, which is where it belongs.

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

bridge: guard local VLAN-0 FDB helpers against NULL vlan group

When CONFIGBRIDGEVLANFILTERING is not set, brvlangroup() and nbpvlangroup() return NULL (brprivate.h stub definitions). The BRBOOLOPTFDBLOCALVLAN0 toggle code is compiled unconditionally and reaches brfdbdeletelocalspervlanport() and brfdbinsertlocalspervlanport(), where the NULL vlan group pointer is dereferenced via listforeachentry(v, &vg->vlanlist, vlist).

The observed crash is in the delete path, triggered when creating a bridge with IFLABRMULTIBOOLOPT containing BRBOOLOPTFDBLOCALVLAN0 via RTMNEWLINK. The insert helper has the same bug pattern.

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000056: 0000 [#1] KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000002b0-0x00000000000002b7] RIP: 0010:brfdbdeletelocalspervlan+0x2b9/0x310 Call Trace: brfdbtogglelocalvlan0+0x452/0x4c0 brtogglefdblocalvlan0+0x31/0x80 net/bridge/br.c:276 brboolopttoggle net/bridge/br.c:313 brbooloptmultitoggle net/bridge/br.c:364 brchangelink net/bridge/brnetlink.c:1542 brdevnewlink net/bridge/brnetlink.c:1575

Add NULL checks for the vlan group pointer in both helpers, returning early when there are no VLANs to iterate. This matches the existing pattern used by other bridge FDB functions such as brfdbadd() and brfdbdelete().

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

drm/vc4: Fix memory leak of BO array in hang state

The hang state's BO array is allocated separately with kzalloc() in vc4savehangstate() but never freed in vc4freehangstate(). Add the missing kfree() for the BO array before freeing the hang state struct.

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

perf/x86/intel/uncore: Skip discovery table for offline dies

This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0.

WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncorepcipmuregister+0x136/0x160 [inteluncore]

Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncorepcipmuregister(), which may trigger the warning above or cause other issues.