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

ipv6: fix possible UAF in ip6finishoutput2()

If skbexpandhead() returns NULL, skb has been freed and associated dst/idev could also have been freed.

We need to hold rcureadlock() to make sure the dst and associated idev are alive.

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

usb: vhci-hcd: Do not drop references before new references are gained

At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.

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

smb: client: fix double put of @cfile in smb2setpathsize()

If smb2compoundop() is called with a valid @cfile and returned -EINVAL, we need to call cifsgetwritablepath() before retrying it as the reference of @cfile was already dropped by previous call.

This fixes the following KASAN splat when running fstests generic/013 against Windows Server 2022:

CIFS: Attempting to mount //w22-fs0/scratch run fstests generic/013 at 2024-09-02 19:48:59 ================================================================== BUG: KASAN: slab-use-after-free in detachifpending+0xab/0x200 Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176

CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: cifsoplockd cifsoplockbreak [cifs] Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? detachifpending+0xab/0x200 printreport+0x156/0x4d9 ? detachifpending+0xab/0x200 ? virtaddrvalid+0x145/0x300 ? physaddr+0x46/0x90 ? detachifpending+0xab/0x200 kasanreport+0xda/0x110 ? detachifpending+0xab/0x200 detachifpending+0xab/0x200 timerdelete+0x96/0xe0 ? pfxtimerdelete+0x10/0x10 ? rcuiswatching+0x20/0x50 trytograbpending+0x46/0x3b0 cancelwork+0x89/0x1b0 ? pfxcancelwork+0x10/0x10 ? kasansavetrack+0x14/0x30 cifsclosedeferredfile+0x110/0x2c0 [cifs] ? pfxcifsclosedeferredfile+0x10/0x10 [cifs] ? pfxdownread+0x10/0x10 cifsoplockbreak+0x4c1/0xa50 [cifs] ? pfxcifsoplockbreak+0x10/0x10 [cifs] ? lockisheldtype+0x85/0xf0 ? markheldlocks+0x1a/0x90 processonework+0x4c6/0x9f0 ? findheldlock+0x8a/0xa0 ? pfxprocessonework+0x10/0x10 ? lockacquired+0x220/0x550 ? listaddvalidorreport+0x37/0x100 workerthread+0x2e4/0x570 ? kthreadparkme+0xd1/0xf0 ? pfxworkerthread+0x10/0x10 kthread+0x17f/0x1c0 ? kthread+0xda/0x1c0 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 1118: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasankmalloc+0xaa/0xb0 cifsnewfileinfo+0xc8/0x9d0 [cifs] cifsatomicopen+0x467/0x770 [cifs] lookupopen.isra.0+0x665/0x8b0 pathopenat+0x4c3/0x1380 dofilpopen+0x167/0x270 dosysopenat2+0x129/0x160 x64syscreat+0xad/0xe0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 83: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x70 poisonslabobject+0xe9/0x160 kasanslabfree+0x32/0x50 kfree+0xf2/0x300 processonework+0x4c6/0x9f0 workerthread+0x2e4/0x570 kthread+0x17f/0x1c0 retfromfork+0x31/0x60 retfromforkasm+0x1a/0x30

Last potentially related work creation: kasansavestack+0x30/0x50 kasanrecordauxstack+0xad/0xc0 insertwork+0x29/0xe0 queuework+0x5ea/0x760 queueworkon+0x6d/0x90 cifsFileInfoput+0x3f6/0x770 [cifs] smb2compoundop+0x911/0x3940 [cifs] smb2setpathsize+0x228/0x270 [cifs] cifssetfilesize+0x197/0x460 [cifs] cifssetattr+0xd9c/0x14b0 [cifs] notifychange+0x4e3/0x740 dotruncate+0xfa/0x180 vfstruncate+0x195/0x200 x64systruncate+0x109/0x150 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

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

nfsd: fix nfsd4deleggetattrconflict in presence of third party lease

It is not safe to dereference fl->c.flcowner without first confirming fl->fllmops is the expected manager. nfsd4deleggetattrconflict() tests fllmops but largely ignores the result and assumes that flcowner is an nfs4delegation anyway. This is wrong.

With this patch we restore the "!= &nfsdleasemngops" case to behave as it did before the change mentioned below. This is the same as the current code, but without any reference to a possible delegation.

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

nfsd: ensure that nfsd4fattrargs.context is zeroed out

If nfsd4encodefattr4 ends up doing a "goto out" before we get to checking for the security label, then args.context will be set to uninitialized junk on the stack, which we'll then try to free. Initialize it early.

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

nfsd: fix potential UAF in nfsd4cbgetattrrelease

Once we drop the delegation reference, the fields embedded in it are no longer safe to access. Do that last.

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

smb: client: fix double put of @cfile in smb2renamepath()

If smb2setpathattr() is called with a valid @cfile and returned -EINVAL, we need to call cifsgetwritablepath() again as the reference of @cfile was already dropped by previous smb2compoundop() call.

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

bnxten: Fix double DMA unmapping for XDPREDIRECT

Remove the dmaunmappageattrs() call in the driver's XDPREDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning:

WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommudmaunmappage+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommudmaunmappage+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? showregs+0x6d/0x80 ? warn+0x89/0x150 ? iommudmaunmappage+0xd5/0x100 ? reportbug+0x16a/0x190 ? handlebug+0x51/0xa0 ? excinvalidop+0x18/0x80 ? iommudmaunmappage+0xd5/0x100 ? iommudmaunmappage+0x35/0x100 dmaunmappageattrs+0x55/0x220 ? bpfprog4d7e87c0d30db711xdpdispatcher+0x64/0x9f bnxtrxxdp+0x237/0x520 [bnxten] bnxtrxpkt+0x640/0xdd0 [bnxten] bnxtpollwork+0x1a1/0x3d0 [bnxten] bnxtpoll+0xaa/0x1e0 [bnxten] napipoll+0x33/0x1e0 netrxaction+0x18a/0x2f0

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

nvme: move stopping keep-alive into nvmeuninitctrl()

Commit 4733b65d82bd ("nvme: start keep-alive after admin queue setup") moves starting keep-alive from nvmestartctrl() into nvmeinitctrlfinish(), but don't move stopping keep-alive into nvmeuninitctrl(), so keep-alive work can be started and keep pending after failing to start controller, finally use-after-free is triggered if nvme host driver is unloaded.

This patch fixes kernel panic when running nvme/004 in case that connection failure is triggered, by moving stopping keep-alive into nvmeuninitctrl().

This way is reasonable because keep-alive is now started in nvmeinitctrlfinish().

igb: cope with large MAXSKBFRAGS