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

crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec

authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, cryptoauthencesndecrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalkmapandcopy(), leading to a kernel panic (DoS).

Add a minimum AAD length check to fail fast on invalid inputs.

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

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.

This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdevdestroy(), leading to use-after-free and improper access to freed resources.

- Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.

- Cancel any pending TMF work that has not started in sdevdestroy().

- Ensure device freeing in sdevdestroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.

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

hwrng: geode - Fix PCI device refcount leak

foreachpcidev() is implemented by pcigetdevice(). The comment of pcigetdevice() says that it will increase the reference count for the returned pcidev and also decrease the reference count for the input pcidev @from if it is not NULL.

If we break foreachpcidev() loop with pdev not NULL, we need to call pcidevput() to decrease the reference count. We add a new struct 'amdgeodepriv' to record pointer of the pcidev and membase, and then add missing pcidevput() for the normal and error path.

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

fou: Don't allow 0 for FOUATTRIPPROTO.

fouudprecv() has the same problem mentioned in the previous patch.

If FOUATTRIPPROTO is set to 0, skb is not freed by fouudprecv() nor "resubmit"-ted in ipprotocoldeliverrcu().

Let's forbid 0 for FOUATTRIPPROTO.

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

HSI: omapssi: Fix refcount leak in ssiprobe

When returning or breaking early from a foreachavailablechildofnode() loop, we need to explicitly call ofnodeput() on the child node to possibly release the node.

bpf: Check skb->transportheader is set in bpfskbcheckmtu

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

rcu: Fix thiscpuread() lockdep warning in rcuforcequiescentstate()

Running rcutorture with non-zero fqsduration module parameter in a kernel built with CONFIGPREEMPTION=y results in the following splat:

BUG: using thiscpuread() in preemptible [00000000] code: rcutorturefqs/398 caller is thiscpupreemptcheck+0x13/0x20 CPU: 3 PID: 398 Comm: rcutorturefqs Not tainted 6.0.0-rc1-yoctodev-standard+ Call Trace: <TASK> dumpstacklvl+0x5b/0x86 dumpstack+0x10/0x16 checkpreemptiondisabled+0xe5/0xf0 thiscpupreemptcheck+0x13/0x20 rcuforcequiescentstate.part.0+0x1c/0x170 rcuforcequiescentstate+0x1e/0x30 rcutorturefqs+0xca/0x160 ? rcutortureboost+0x430/0x430 kthread+0x192/0x1d0 ? kthreadcompleteandexit+0x30/0x30 retfromfork+0x22/0x30 </TASK>

The problem is that rcuforcequiescentstate() uses thiscpuread() in preemptible code instead of the proper rawcpuread(). This commit therefore changes thiscpuread() to rawcpuread().

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

netfilter: nftables: fix use-after-free in nftablesaddchain()

nftablesaddchain() publishes the chain to table->chains via listaddtailrcu() (in nftchainadd()) before registering hooks. If nftablesregisterhook() then fails, the error path calls nftchaindel() (listdelrcu()) followed by nftableschaindestroy() with no RCU grace period in between.

This creates two use-after-free conditions:

1) Control-plane: nftablesdumpchains() traverses table->chains under rcureadlock(). A concurrent dump can still be walking the chain when the error path frees it.

2) Packet path: for NFPROTOINET, nfregisternethook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nftdochain() via the transient IPv4 hook can still be dereferencing chain->blobgenX when the error path frees the chain.

Add synchronizercu() between nftchaindel() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.

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

bpf: Fix reference count leak in bpfprogtestrunxdp()

syzbot is reporting

unregisternetdevice: waiting for sit0 to become free. Usage count = 2

problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().

According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().

Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().

fbdev: smscufx: properly copy ioctl memory to kernelspace

bonding: annotate data-races around slave->lastrx

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

can: usb8dev: usb8devreadbulkcallback(): fix URB memory leak

Fix similar memory leak as in commit 7352e1d5932a ("can: gsusb: gsusbreceivebulkcallback(): fix URB memory leak").

In usb8devopen() -> usb8devstart(), the URBs for USB-in transfers are allocated, added to the priv->rxsubmitted anchor and submitted. In the complete callback usb8devreadbulkcallback(), the URBs are processed and resubmitted. In usb8devclose() -> unlinkallurbs() the URBs are freed by calling usbkillanchoredurbs(&priv->rxsubmitted).

However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usbkillanchoredurbs().

Fix the memory leak by anchoring the URB in the usb8devreadbulkcallback() to the priv->rxsubmitted anchor.

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

net: usb: rtl8150: fix memory leak on usbsubmiturb() failure

In asyncsetregisters(), when usbsubmiturb() fails, the allocated asyncreq structure and URB are not freed, causing a memory leak.

The completion callback asyncsetregcb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked.

Fix this by freeing both the URB and the request structure in the error path when usbsubmiturb() fails.

ethtool: Avoid overflowing userspace buffer on stats query

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

Input: lkkbd - disable pending work before freeing device

lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.

lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.

Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().

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

macintosh/machid: fix race condition in machidtoggleemumouse

The following warning appears when running syzkaller, and this issue also exists in the mainline code.

------------[ cut here ]------------ listadd double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/listdebug.c:35 listaddvalidorreport+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:listaddvalidorreport+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> inputregisterhandler+0xb3/0x210 machidstartemulation+0x1c5/0x290 machidtoggleemumouse+0x20a/0x240 procsyscallhandler+0x4c2/0x6e0 newsyncwrite+0x1b1/0x2d0 vfswrite+0x709/0x950 ksyswrite+0x12a/0x250 dosyscall64+0x5a/0x110 entrySYSCALL64afterhwframe+0x78/0xe2

The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in machidtoggleemumouse(). Both processes read oldval=0, then both try to register the input handler, leading to a double listadd of the same handler.

CPU0 CPU1 ------------------------- ------------------------- vfswrite() //write 1 vfswrite() //write 1 procsyswrite() procsyswrite() machidtoggleemumouse() machidtoggleemumouse() oldval = valp // oldval=0 oldval = valp // oldval=0 mutexlockkillable() procdointvec() // valp=1 machidstartemulation() inputregisterhandler() mutexunlock() mutexlockkillable() procdointvec() machidstartemulation() inputregisterhandler() //Trigger Warning mutexunlock()

Fix this by moving the oldval read inside the mutex lock region.

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

iommu/mediatek: fix use-after-free on probe deferral

The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers.

Fix this by keeping the references as expected while the iommu driver is bound.

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

drm/sysfb: Do not dereference NULL pointer in plane reset

The plane state in drmgemresetshadowplane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL.

v2: - fix typo in commit description (Javier)

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

net: ethernet: ti: netcp: Standardize knavdmaopenchannel to return NULL on error

Make knavdmaopenchannel consistently return NULL on error instead of ERRPTR. Currently the header include/linux/soc/ti/knavdma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERRPTR on failure, causing inconsistency in the users. This results in a crash in netcpfreenavigatorresources as followed (trimmed):

Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] pgd=80000800207003, pmd=82ffda003, pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knavdmaclosechannel+0x30/0x19c LR is at netcpfreenavigatorresources+0x2c/0x28c

[... TRIM...]

Call trace: knavdmaclosechannel from netcpfreenavigatorresources+0x2c/0x28c netcpfreenavigatorresources from netcpndoopen+0x430/0x46c netcpndoopen from devopen+0x114/0x29c devopen from devchangeflags+0x190/0x208 devchangeflags from netifchangeflags+0x1c/0x58 netifchangeflags from devchangeflags+0x38/0xa0 devchangeflags from ipautoconfig+0x2c4/0x11f0 ipautoconfig from dooneinitcall+0x58/0x200 dooneinitcall from kernelinitfreeable+0x1cc/0x238 kernelinitfreeable from kernelinit+0x1c/0x12c kernelinit from retfromfork+0x14/0x38 [... TRIM...]

Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcpcore.c so the impact is limited.

Note, this change, in effect reverts commit 5b6cb43b4d62 ("net: ethernet: ti: netcpcore: return error while dma channel open issue"), but provides a less error prone implementation.

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

platform/x86: intel: punitipc: fix memory corruption

This passes the address of the pointer "&punitipcdev" when the intent was to pass the pointer itself "punitipcdev" (without the ampersand). This means that the:

complete(&ipcdev->cmdcomplete);

in intelpunitioc() will write to a wrong memory address corrupting it.

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

mt76: mt7615: Fix memory leak in mt7615mcuwtblstaadd()

In mt7615mcuwtblstaadd(), an skb sskb is allocated. If the subsequent call to mt76connacmcuallocwtblreq() fails, the function returns an error without freeing sskb, leading to a memory leak.

Fix this by calling devkfreeskb() on sskb in the error handling path to ensure it is properly released.

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

mlx5: Fix default values in create CQ

Currently, CQs without a completion function are assigned the mlx5addcqtotasklet function by default. This is problematic since only user CQs created through the mlx5ib driver are intended to use this function.

Additionally, all CQs that will use doorbells instead of polling for completions must call mlx5cqarm. However, the default CQ creation flow leaves a valid value in the CQ's armdb field, allowing FW to send interrupts to polling-only CQs in certain corner cases.

These two factors would allow a polling-only kernel CQ to be triggered by an EQ interrupt and call a completion function intended only for user CQs, causing a null pointer exception.

Some areas in the driver have prevented this issue with one-off fixes but did not address the root cause.

This patch fixes the described issue by adding defaults to the create CQ flow. It adds a default dummy completion function to protect against null pointer exceptions, and it sets an invalid command sequence number by default in kernel CQs to prevent the FW from sending an interrupt to the CQ until it is armed. User CQs are responsible for their own initialization values.

Callers of mlx5corecreatecq are responsible for changing the completion function and arming the CQ per their needs.

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

scsi: qla2xxx: Fix improper freeing of purex item

In qla2xxxprocesspurlsiocb(), an item is allocated via qla27xxcopymultiplepkt(), which internally calls qla24xxallocpurexitem().

The qla24xxallocpurexitem() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc().

An error handling path in qla2xxxprocesspurlsiocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption.

Fix this by using the correct deallocation function, qla24xxfreepurexitem(), which properly handles both dynamically allocated and pre-allocated items.

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

ksmbd: close accepted socket when per-IP limit rejects connection

When the per-IP connection limit is exceeded in ksmbdkthreadfn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS.

Release clientsk before continuing.

This bug was found with ZeroPath.

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

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

PCI: pnvphp: Clean up allocated IRQs on unplug

When the root of a nested PCIe bridge configuration is unplugged, the pnvphp driver leaked the allocated IRQ resources for the child bridges' hotplug event notifications, resulting in a panic.

Fix this by walking all child buses and deallocating all its IRQ resources before calling pcihpremovedevices().

Also modify the lifetime of the workqueue at struct pnvphpslot::wq so that it is only destroyed in pnvphpfreeslot(), instead of pnvphpdisableirq(). This is required since pnvphpdisableirq() will now be called by workers triggered by hot unplug interrupts, so the workqueue needs to stay allocated.

The abridged kernel panic that occurs without this patch is as follows:

WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msidevicedatarelease+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msidevicedatarelease+0x34/0x9c (unreliable) releasenodes+0x64/0x13c devresreleaseall+0xc0/0x140 devicedel+0x2d4/0x46c pcidestroydev+0x5c/0x194 pcihpremovedevices+0x90/0x128 pcihpremovedevices+0x44/0x128 pnvphpdisableslot+0x54/0xd4 powerwritefile+0xf8/0x18c pcislotattrstore+0x40/0x5c sysfskfwrite+0x64/0x78 kernfsfopwriteiter+0x1b0/0x290 vfswrite+0x3bc/0x50c ksyswrite+0x84/0x140 systemcallexception+0x124/0x230 systemcallvectoredcommon+0x15c/0x2ec

[bhelgaas: tidy comments]

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

RDMA/irdma: Fix data race on CQP request done

KCSAN detects a data race on cqprequest->requestdone memory location which is accessed locklessly in irdmahandlecqpop while being updated in irdmacqpcehandler.

Annotate lockless intent with READONCE/WRITEONCE to avoid any compiler optimizations like load fusing and/or KCSAN warning.

[222808.417128] BUG: KCSAN: data-race in irdmacqpcehandler [irdma] / irdmawaitevent [irdma]

[222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5: [222808.417610] irdmacqpcehandler+0x21e/0x270 [irdma] [222808.417725] cqpcomplworker+0x1b/0x20 [irdma] [222808.417827] processonework+0x4d1/0xa40 [222808.417835] workerthread+0x319/0x700 [222808.417842] kthread+0x180/0x1b0 [222808.417852] retfromfork+0x22/0x30

[222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1: [222808.417995] irdmawaitevent+0x1e2/0x2c0 [irdma] [222808.418099] irdmahandlecqpop+0xae/0x170 [irdma] [222808.418202] irdmacqpcqdestroycmd+0x70/0x90 [irdma] [222808.418308] irdmapudadelersrc+0x46d/0x4d0 [irdma] [222808.418411] irdmartdeinithw+0x179/0x1d0 [irdma] [222808.418514] irdmaibdeallocdevice+0x11/0x40 [irdma] [222808.418618] ibdeallocdevice+0x2a/0x120 [ibcore] [222808.418823] ibunregisterdevice+0xde/0x100 [ibcore] [222808.418981] ibunregisterdevice+0x22/0x40 [ibcore] [222808.419142] irdmaibunregisterdevice+0x70/0x90 [irdma] [222808.419248] i40iwclose+0x6f/0xc0 [irdma] [222808.419352] i40eclientdeviceunregister+0x14a/0x180 [i40e] [222808.419450] i40iwremove+0x21/0x30 [irdma] [222808.419554] auxiliarybusremove+0x31/0x50 [222808.419563] deviceremove+0x69/0xb0 [222808.419572] devicereleasedriverinternal+0x293/0x360 [222808.419582] driverdetach+0x7c/0xf0 [222808.419592] busremovedriver+0x8c/0x150 [222808.419600] driverunregister+0x45/0x70 [222808.419610] auxiliarydriverunregister+0x16/0x30 [222808.419618] irdmaexitmodule+0x18/0x1e [irdma] [222808.419733] dosysdeletemodule.constprop.0+0x1e2/0x310 [222808.419745] x64sysdeletemodule+0x1b/0x30 [222808.419755] dosyscall64+0x39/0x90 [222808.419763] entrySYSCALL64afterhwframe+0x63/0xcd

[222808.419829] value changed: 0x01 -> 0x03

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

drm/ttm: Don't leak a resource on eviction error

On eviction errors other than -EMULTIHOP we were leaking a resource. Fix.

v2: - Avoid yet another goto (Andi Shyti)

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

media: usb: siano: Fix use after free bugs caused by dosubmiturb

There are UAF bugs caused by dosubmiturb(). One of the KASan reports is shown below:

[ 36.403605] BUG: KASAN: use-after-free in workerthread+0x4a2/0x890 [ 36.406105] Read of size 8 at addr ffff8880059600e8 by task kworker/0:2/49 [ 36.408316] [ 36.408867] CPU: 0 PID: 49 Comm: kworker/0:2 Not tainted 6.2.0-rc3-15798-g5a41237ad1d4-dir8 [ 36.411696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584 [ 36.416157] Workqueue: 0x0 (events) [ 36.417654] Call Trace: [ 36.418546] <TASK> [ 36.419320] dumpstacklvl+0x96/0xd0 [ 36.420522] printaddressdescription+0x75/0x350 [ 36.421992] printreport+0x11b/0x250 [ 36.423174] ? rawspinlockirqsave+0x87/0xd0 [ 36.424806] ? virtaddrvalid+0xcf/0x170 [ 36.426069] ? workerthread+0x4a2/0x890 [ 36.427355] kasanreport+0x131/0x160 [ 36.428556] ? workerthread+0x4a2/0x890 [ 36.430053] workerthread+0x4a2/0x890 [ 36.431297] ? workerclrflags+0x90/0x90 [ 36.432479] kthread+0x166/0x190 [ 36.433493] ? kthreadblkcg+0x50/0x50 [ 36.434669] retfromfork+0x22/0x30 [ 36.435923] </TASK> [ 36.436684] [ 36.437215] Allocated by task 24: [ 36.438289] kasansettrack+0x50/0x80 [ 36.439436] kasankmalloc+0x89/0xa0 [ 36.440566] smsusbprobe+0x374/0xc90 [ 36.441920] usbprobeinterface+0x2d1/0x4c0 [ 36.443253] reallyprobe+0x1d5/0x580 [ 36.444539] driverprobedevice+0xe3/0x130 [ 36.446085] driverprobedevice+0x49/0x220 [ 36.447423] deviceattachdriver+0x19e/0x1b0 [ 36.448931] busforeachdrv+0xcb/0x110 [ 36.450217] deviceattach+0x132/0x1f0 [ 36.451470] busprobedevice+0x59/0xf0 [ 36.452563] deviceadd+0x4ec/0x7b0 [ 36.453830] usbsetconfiguration+0xc63/0xe10 [ 36.455230] usbgenericdriverprobe+0x3b/0x80 [ 36.456166] printk: console [ttyGS0] disabled [ 36.456569] usbprobedevice+0x90/0x110 [ 36.459523] reallyprobe+0x1d5/0x580 [ 36.461027] driverprobedevice+0xe3/0x130 [ 36.462465] driverprobedevice+0x49/0x220 [ 36.463847] deviceattachdriver+0x19e/0x1b0 [ 36.465229] busforeachdrv+0xcb/0x110 [ 36.466466] deviceattach+0x132/0x1f0 [ 36.467799] busprobedevice+0x59/0xf0 [ 36.469010] deviceadd+0x4ec/0x7b0 [ 36.470125] usbnewdevice+0x863/0xa00 [ 36.471374] hubevent+0x18c7/0x2220 [ 36.472746] processonework+0x34c/0x5b0 [ 36.474041] workerthread+0x4b7/0x890 [ 36.475216] kthread+0x166/0x190 [ 36.476267] retfromfork+0x22/0x30 [ 36.477447] [ 36.478160] Freed by task 24: [ 36.479239] kasansettrack+0x50/0x80 [ 36.480512] kasansavefreeinfo+0x2b/0x40 [ 36.481808] kasanslabfree+0x122/0x1a0 [ 36.483173] kmemcachefree+0xc4/0x200 [ 36.484563] smsusbtermdevice+0xcd/0xf0 [ 36.485896] smsusbprobe+0xc85/0xc90 [ 36.486976] usbprobeinterface+0x2d1/0x4c0 [ 36.488303] reallyprobe+0x1d5/0x580 [ 36.489498] driverprobedevice+0xe3/0x130 [ 36.491140] driverprobedevice+0x49/0x220 [ 36.492475] deviceattachdriver+0x19e/0x1b0 [ 36.493988] busforeachdrv+0xcb/0x110 [ 36.495171] deviceattach+0x132/0x1f0 [ 36.496617] busprobedevice+0x59/0xf0 [ 36.497875] deviceadd+0x4ec/0x7b0 [ 36.498972] usbsetconfiguration+0xc63/0xe10 [ 36.500264] usbgenericdriverprobe+0x3b/0x80 [ 36.501740] usbprobedevice+0x90/0x110 [ 36.503084] reallyprobe+0x1d5/0x580 [ 36.504241] driverprobedevice+0xe3/0x130 [ 36.505548] driverprobedevice+0x49/0x220 [ 36.506766] deviceattachdriver+0x19e/0x1b0 [ 36.508368] busforeachdrv+0xcb/0x110 [ 36.509646] deviceattach+0x132/0x1f0 [ 36.510911] busprobedevice+0x59/0xf0 [ 36.512103] deviceadd+0x4ec/0x7b0 [ 36.513215] usbnewdevice+0x863/0xa00 [ 36.514736] hubevent+0x18c7/0x2220 [ 36.516130] processonework+ ---truncated---

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

cifs: fix potential oops in cifsoplockbreak

With deferred close we can have closes that race with lease breaks, and so with the current checks for whether to send the lease response, oplockresponse(), this can mean that an unmount (killsb) can occur just before we were checking if the tcon->ses is valid. See below:

[Fri Aug 4 04:12:50 2023] RIP: 0010:cifsoplockbreak+0x1f7/0x5b0 [cifs] [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39 [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206 [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009 [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188 [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900 [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138 [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000 [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000 [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0 [Fri Aug 4 04:12:50 2023] Call Trace: [Fri Aug 4 04:12:50 2023] <TASK> [Fri Aug 4 04:12:50 2023] processonework+0x225/0x3d0 [Fri Aug 4 04:12:50 2023] workerthread+0x4d/0x3e0 [Fri Aug 4 04:12:50 2023] ? processonework+0x3d0/0x3d0 [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150 [Fri Aug 4 04:12:50 2023] ? setkthreadstruct+0x50/0x50 [Fri Aug 4 04:12:50 2023] retfromfork+0x22/0x30 [Fri Aug 4 04:12:50 2023] </TASK>

To fix this change the ordering of the checks before sending the oplockresponse to first check if the openFileList is empty.