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

vhost: move vdpa group bound check to vhostvdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpasim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.

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

LoongArch: Make cpumaskofnode() robust against NUMANONODE

The arch definition of cpumaskofnode() cannot handle NUMANONODE - which is a valid index - so add a check for this.

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

iouring/kbuf: check if target buffer list is still legacy on recycle

There's a gap between when the buffer was grabbed and when it potentially gets recycled, where if the list is empty, someone could've upgraded it to a ring provided type. This can happen if the request is forced via io-wq. The legacy recycling is missing checking if the bufferlist still exists, and if it's of the correct type. Add those checks.

EDAC/mc: Fix error path ordering in edacmcalloc()

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

tcp: drop secpath at the same time as we currently drop dst

Xiumei reported hitting the WARN in xfrm6tunnelnetexit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns

The xfrmstate found on spibyaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrmstate), which is still attached to an skb. This skb is not leaked, it ends up on skreceivequeue and then gets defer-free'd by skbattemptdeferfree.

The problem happens when we defer freeing an skb (push it on one CPU's deferlist), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrmstate that we don't expect at this point.

We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcpfilter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.

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

block: fix uaf for flush rq while iterating tags

blkmqclearflushrqmapping() is not called during scsi probe, by checking blkqueueinitdone(). However, QUEUEFLAGINITDONE is cleared in delgendisk by commit aec89dc5d421 ("block: keep qusagecounter in atomic mode after delgendisk"), hence for disk like scsi, following blkmqdestroyqueue() will not clear flush rq from tags->rqs[] as well, cause following uaf that is found by our syzkaller for v6.6:

================================================================== BUG: KASAN: slab-use-after-free in blkmqfindandgetreq+0x16e/0x1a0 block/blk-mq-tag.c:261 Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909

CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32 Workqueue: kblockd blkmqtimeoutwork Call Trace:

dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x91/0xf0 lib/dumpstack.c:106 printaddressdescription.constprop.0+0x66/0x300 mm/kasan/report.c:364 printreport+0x3e/0x70 mm/kasan/report.c:475 kasanreport+0xb8/0xf0 mm/kasan/report.c:588 blkmqfindandgetreq+0x16e/0x1a0 block/blk-mq-tag.c:261 btiter block/blk-mq-tag.c:288 [inline] sbitmapforeachset include/linux/sbitmap.h:295 [inline] sbitmapforeachset include/linux/sbitmap.h:316 [inline] btforeach+0x455/0x790 block/blk-mq-tag.c:325 blkmqqueuetagbusyiter+0x320/0x740 block/blk-mq-tag.c:534 blkmqtimeoutwork+0x1a3/0x7b0 block/blk-mq.c:1673 processonework+0x7c4/0x1450 kernel/workqueue.c:2631 processscheduledworks kernel/workqueue.c:2704 [inline] workerthread+0x804/0xe40 kernel/workqueue.c:2785 kthread+0x346/0x450 kernel/kthread.c:388 retfromfork+0x4d/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1b/0x30 arch/x86/entry/entry64.S:293

Allocated by task 942: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasankmalloc mm/kasan/common.c:374 [inline] kasankmalloc mm/kasan/common.c:383 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasankmalloc include/linux/kasan.h:198 [inline] dokmallocnode mm/slabcommon.c:1007 [inline] kmallocnode+0x69/0x170 mm/slabcommon.c:1014 kmallocnode include/linux/slab.h:620 [inline] kzallocnode include/linux/slab.h:732 [inline] blkallocflushqueue+0x144/0x2f0 block/blk-flush.c:499 blkmqallochctx+0x601/0x940 block/blk-mq.c:3788 blkmqallocandinithctx+0x27f/0x330 block/blk-mq.c:4261 blkmqreallochwctxs+0x488/0x5e0 block/blk-mq.c:4294 blkmqinitallocatedqueue+0x188/0x860 block/blk-mq.c:4350 blkmqinitqueuedata block/blk-mq.c:4166 [inline] blkmqinitqueue+0x8d/0x100 block/blk-mq.c:4176 scsiallocsdev+0x843/0xd50 drivers/scsi/scsiscan.c:335 scsiprobeandaddlun+0x77c/0xde0 drivers/scsi/scsiscan.c:1189 scsiscantarget+0x1fc/0x5a0 drivers/scsi/scsiscan.c:1727 scsiscanchannel drivers/scsi/scsiscan.c:1815 [inline] scsiscanchannel+0x14b/0x1e0 drivers/scsi/scsiscan.c:1791 scsiscanhostselected+0x2fe/0x400 drivers/scsi/scsiscan.c:1844 scsiscan+0x3a0/0x3f0 drivers/scsi/scsisysfs.c:151 storescan+0x2a/0x60 drivers/scsi/scsisysfs.c:191 devattrstore+0x5c/0x90 drivers/base/core.c:2388 sysfskfwrite+0x11c/0x170 fs/sysfs/file.c:136 kernfsfopwriteiter+0x3fc/0x610 fs/kernfs/file.c:338 callwriteiter include/linux/fs.h:2083 [inline] newsyncwrite+0x1b4/0x2d0 fs/readwrite.c:493 vfswrite+0x76c/0xb00 fs/readwrite.c:586 ksyswrite+0x127/0x250 fs/readwrite.c:639 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x70/0x120 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x78/0xe2

Freed by task 244687: kasansavestack+0x22/0x50 mm/kasan/common.c:45 kasansettrack+0x25/0x30 mm/kasan/common.c:52 kasansavefreeinfo+0x2b/0x50 mm/kasan/generic.c:522 kasanslabfree mm/kasan/common.c:236 [inline] kasanslabfree+0x12a/0x1b0 mm/kasan/common.c:244 kasanslabfree include/linux/kasan.h:164 [in ---truncated---

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

NFSD: fix hang in nfsd4shutdowncallback

If nfs4client is in courtesy state then there is no point to send the callback. This causes nfsd4shutdowncallback to hang since clcbinflight is not 0. This hang lasts about 15 minutes until TCP notifies NFSD that the connection was dropped.

This patch modifies nfsd4runcbwork to skip the RPC call if nfs4client is in courtesy state.

bpf: Fix overloading of MEMUNINIT's meaning

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

dmaengine: dw: dmamux: fix OF node leak on route allocation failure

Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.

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

net/mlx5: lag: Check for LAG device before creating debugfs

mlx5lagdevaddmdev() may return 0 (success) even when an error occurs that is handled gracefully. Consequently, the initialization flow proceeds to call mlx5ldevadddebugfs() even when there is no valid LAG context.

mlx5ldevadddebugfs() blindly created the debugfs directory and attributes. This exposed interfaces (like the members file) that rely on a valid ldev pointer, leading to potential NULL pointer dereferences if accessed when ldev is NULL.

Add a check to verify that mlx5lagdev(dev) returns a valid pointer before attempting to create the debugfs entries.

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

net/sched: actskbedit: fix divide-by-zero in tcfskbedithash()

Commit 38a6f0865796 ("net: sched: support hash selecting tx queue") added SKBEDITFTXQSKBHASH support. The inclusive range size is computed as:

mappingmod = queuemappingmax - queuemapping + 1;

The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queuemapping=0 and queuemappingmax=U16MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcfskbedithash() could trigger a divide-by-zero:

queuemapping += skbgethash(skb) % params->mappingmod;

Compute mappingmod in a wider type and reject ranges larger than U16MAX to prevent params->mappingmod from becoming 0 and avoid the crash.

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

smb: client: prevent races in ->queryinterfaces()

It was possible for two query interface works to be concurrently trying to update the interfaces.

Prevent this by checking and updating ifacelastupdate under ifacelock.

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

btrfs: fix transaction abort on file creation due to name hash collision

If we attempt to create several files with names that result in the same hash, we have to pack them in same dir item and that has a limit inherent to the leaf size. However if we reach that limit, we trigger a transaction abort and turns the filesystem into RO mode. This allows for a malicious user to disrupt a system, without the need to have administration privileges/capabilities.

Reproducer:

$ cat exploit-hash-collisions.sh #!/bin/bash

DEV=/dev/sdi MNT=/mnt/sdi

# Use smallest node size to make the test faster and require fewer file # names that result in hash collision. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT

# List of names that result in the same crc32c hash for btrfs. declare -a names=( 'foobar' '%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUeL:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC' 'AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0Il5Fnam04CGIg=8@U:Z' 'CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4' 'ET:vk@rFU4tsvMB0$Cp=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:' 'HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDHVooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7IeOsByOkBOO' 'Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us' 'KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJj4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%eujl%WPd4U2BI7qooOSr85J-C2V$LfY' 'NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAbF%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO' 'Oj42AQAEzRoTxa5OuSKIr=AlwGMy132v4g3Pdq1GvUG9874YseIFQ6QU' 'Ono7avN5GjC:6dBJ' 'WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtUcfW2:%2am' 'WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4LXBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k' 'XKyH=OsOAF3p%uziGFZVr$ivrvhVgD@1u%5RtrV-glvqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2' 'd3uUR6OFEwZr%ns1XH@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd' 'ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2GoGQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm' 'evqk743Y@dvZAiG5J05LROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$2rA9mKZ' 'gkgUtnihWXsZQTEkrMAWIxir09k3t7jkIK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPOppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky' 'hNgsG8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrVWVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS' 'isA7JVzN12xCxVPJZqoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz' 'kiJfgcdZFDiOptjgH5PN9-PSyLO4fbk:u52tz35lViXiJ6cx7pwjTtKy-XGaQ5IefmpJ4NZqGsqCsKuqOOBgf9LkUdffHet@Wu' 'lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pgb6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYrqrB49i=pA--@WqWLIuX7o1SSfS@2FSiUZN' 'rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=' 'uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn' 'UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C' 'y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW' '8-HCSgH5B%K7P8jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc' 'YPPh:IFt2mtR6XWSmjHptXLhbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA2MBwZ8Dr4=R1D%7-mC ---truncated---

A use-after-free vulnerability was found in the Linux kernel's ext4 filesystem in the way it handled the extra inode size for extended attributes. This flaw could allow a privileged local user to cause a system crash or other undefined behaviors.

An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c has a use-after-free and OOPS for SMB2TREEDISCONNECT.

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

mm/memory: fix spurious warning when unmapping device-private/exclusive pages

Device private and exclusive entries are only supported for anonymous folios. This condition is tested in migratedevicepages() and makedeviceexclusive() using foliotestanon(). However the unmap path tests this assumption using vmaisanonymous().

This is wrong because whilst anonymous VMAs can only contain folios where foliotestanon() is true the opposite relation does not hold. A folio for which foliotestanon() is true does not imply vmaisanonymous() is true. Such a condition can occur if for example a folio is part of a private filebacked mapping.

In this case vmaisanonymous() is false as the mapping is filebacked, but foliotestanon() may be true, thus permitting devices to migrate the folio to device private memory. This can lead to the following spurious warnings during process teardown:

[ 772.737706] ------------[ cut here ]------------ [ 772.739201] WARNING: mm/memory.c:1754 at unmappagerange.cold+0x26/0x18a, CPU#17: hmm-tests/2041 [ 772.742050] Modules linked in: testhmm nvidiauvm(O) nvidia(O) [ 772.743959] CPU: 17 UID: 0 PID: 2041 Comm: hmm-tests Tainted: G W O 7.0.0+ #387 PREEMPT(full) [ 772.747104] Tainted: [W]=WARN, [O]=OOTMODULE [ 772.748509] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 772.752117] RIP: 0010:unmappagerange.cold+0x26/0x18a [ 772.753780] Code: 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 <0f> 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02 [ 772.759602] RSP: 0018:ffff888112607550 EFLAGS: 00010286 [ 772.761310] RAX: ffff88811bbf4dc0 RBX: dffffc0000000000 RCX: ffffea03e9bfffd8 [ 772.763583] RDX: 1ffff1102377e9c1 RSI: 0000000000000008 RDI: ffff88811bbf4e08 [ 772.765914] RBP: 0000000000000006 R08: ffff8881059f7448 R09: ffffed10224c0e68 [ 772.768184] R10: ffff888112607347 R11: 0000000000000001 R12: 0000000000000001 [ 772.770461] R13: ffffea03e9bfffc0 R14: ffff888112607908 R15: ffffea03e9bfffc0 [ 772.772782] FS: 00007f327caa2780(0000) GS:ffff888427b7d000(0000) knlGS:0000000000000000 [ 772.775328] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 772.777187] CR2: 00007f327ca89000 CR3: 00000001994d5000 CR4: 00000000000006f0 [ 772.779135] Call Trace: [ 772.779792] <TASK> [ 772.780317] ? dmirrorintervalinvalidate+0x1a3/0x290 [testhmm] [ 772.781873] ? vmnormalpagepud+0x2b0/0x2b0 [ 772.782992] ? rwlockinit+0x150/0x150 [ 772.784006] ? lockrelease+0x216/0x2b0 [ 772.785008] ? mmunotifierinvalidaterangestart+0x505/0x6e0 [ 772.786522] ? lockrelease+0x216/0x2b0 [ 772.787498] ? unmapsinglevma+0xb6/0x210 [ 772.788573] unmapvmas+0x27d/0x520 [ 772.789506] ? unmapsinglevma+0x210/0x210 [ 772.790607] ? masupdategap.part.0+0x620/0x620 [ 772.791834] unmapregion+0x19e/0x350 [ 772.792769] ? removevma+0x130/0x130 [ 772.793684] ? masallocnodes+0x1f2/0x300 [ 772.794730] vmscompletemunmapvmas+0x8c1/0xe20 [ 772.795926] ? unmapregion+0x350/0x350 [ 772.796917] dovmialignmunmap+0x36a/0x4e0 [ 772.798018] ? lockrelease+0x216/0x2b0 [ 772.799024] ? vmashrink+0x620/0x620 [ 772.799983] dovmimunmap+0x150/0x2c0 [ 772.800939] vmmunmap+0x161/0x2c0 [ 772.801872] ? expanddownwards+0xd60/0xd60 [ 772.802948] ? clockeventsprogramevent+0x1ef/0x540 [ 772.804217] ? lockrelease+0x216/0x2b0 [ 772.805158] x64sysmunmap+0x59/0x80 [ 772.805776] dosyscall64+0xfc/0x670 [ 772.806336] ? irqentryexit+0xda/0x580 [ 772.806976] entrySYSCALL64afterhwframe+0x4b/0x53 [ 772.807772] RIP: 0033:0x7f327cbb2717 [ 772.808323] Code: 73 01 c3 48 8b 0d f9 76 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ---truncated---

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

firmwareloader: fix device reference leak in firmwareuploadregister()

firmwareuploadregister() -> fwcreateinstance() -> deviceinitialize()

After fwcreateinstance() succeeds, the lifetime of the embedded struct device is expected to be managed through the device core reference counting, since fwcreateinstance() has already called deviceinitialize().

In firmwareuploadregister(), if alloclookupfwpriv() fails after fwcreateinstance() succeeds, the code reaches freefwsysfs and frees fwsysfs directly instead of releasing the device reference with putdevice(). This may leave the reference count of the embedded struct device unbalanced, resulting in a refcount leak.

The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using putdevice(fwdev) in the failure path and letting fwdevrelease() handle the final cleanup, instead of freeing the instance directly from the error path.

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

mptcp: allow subflow rcv wnd to shrink

In MPTCP connection, the window field in the TCP header refers to the MPTCP-level rcvnxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time.

At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog).

As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving.

Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.

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

serial: 8250dw: unregister 8250 port if clknotifierregister() fails

dw8250probe() registers the 8250 port via serial8250register8250port() and then, if the device has a clock, registers a clock notifier. If clknotifierregister() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250unregisterport() lives in dw8250remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved privatedata and serialin/serialout callbacks), so any access to that port slot before a rebind is a use-after-free hazard.

Unregister the port on the clknotifierregister() error path.

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

usb: gadget: udc: Fix use-after-free in gadgetmatchdriver

The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usbdelgadget() frees the udc memory (e.g., via mode-switch work) while gadgetmatchdriver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed:

[39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : pistrcmp+0x20/0x140 [39430.911441][ T1171] lr : gadgetmatchdriver+0x34/0x60 ... [39430.911890][ T1171] usbgadgetregisterdriverowner+0x50/0xf8 [39430.911910][ T1171] gadgetdevdescUDCstore+0xf4/0x140 [39430.931308][ T1171] configfswriteiter+0xec/0x134

[39430.957058][ T1171] Workqueue: eventsfreezable dwc3setmode [39430.957287][ T1171] dwc3gadgetexit+0x34/0x8c [39430.957304][ T1171] dwc3setmode+0xc0/0x664

Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usbgadgetrelease() routine to the core. When the gadget is added, usbaddgadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usbgadgetrelease() drops the reference to the udc and then calls the gadget's release routine.

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

scsi: mpi3mr: Fix issues in mpi3mrgetalltgtinfo()

The function mpi3mrgetalltgtinfo() has four issues:

1) It calculates valid entry length in alltgtinfo assuming the header part of the struct mpi3mrdevicemapinfo would equal to sizeof(u32). The correct size is sizeof(u64).

2) When it calculates the valid entry length kernentrylen, it excludes one entry by subtracting 1 from numdevices.

3) It copies numdevice by calling memcpy(). Substitution is enough.

4) It does not specify the calculated length to sgcopyfrombuffer(). Instead, it specifies the payload length which is larger than the alltgtinfo size. It causes "BUG: KASAN: slab-out-of-bounds".

Fix the issues by using the correct header size, removing the subtraction from numdevices, replacing the memcpy() with substitution and specifying the correct length to sgcopyfrombuffer().

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

riscv: Fix register corruption from uninitialized cregs on error

compatriscvgprset() calls cregstoregs() unconditionally, even when userregsetcopyin() fails. Since cregs is an uninitialized stack variable, a copyin failure causes uninitialized stack data to be written into the target task's ptregs, corrupting its register state and potentially leaking kernel stack contents.

compatrestoresigcontext() has the same issue: it calls cregstoregs() even when copyfromuser() fails, leading to the same corruption of the signal-returning task's register state on error.

Only call cregstoregs() when the user copy succeeds.

drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11

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

netfilter: nftables: add hook transactions for device deletions

Restore the flag that indicates that the hook is going away, ie. NFTHOOKREMOVE, but add a new transaction object to track deletion of hooks without altering the basechain/flowtable hooklist during the preparation phase.

The existing approach that moves the hook from the basechain/flowtable hooklist to transaction hooklist breaks netlink dump path readers of this RCU-protected list.

It should be possible use an array for nfttranshook to store the deleted hooks to compact the representation but I am not expecting many hook object, specially now that wildcard support for devices is in place.

Note that the nfttranschainhooks() list contains a list of struct nfttranshook objects for DELCHAIN and DELFLOWTABLE commands, while this list stores struct nfthook objects for NEWCHAIN and NEWFLOWTABLE. Note that new commands can be updated to use nfttranshook for consistency.

This patch also adapts the event notification path to deal with the list of hook transactions.

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

drm/amdgpu/jpeg: set nouserfence for JPEG v4.0 ring

JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences.

(cherry picked from commit 8d0cac9478a3f046279c657d6a2545de49ae675a)

drm/amdgpu/vcn: set nouserfence for VCN v4.0 enc ring

drm/msm: always recover the gpu

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

fsnotify: fix inode reference leak in fsnotifyrecalcmask()

fsnotifyrecalcmask() fails to handle the return value of fsnotifyrecalcmask(), which may return an inode pointer that needs to be released via fsnotifydropobject() when the connector's HASIREF flag transitions from set to cleared.

This manifests as a hung task with the following call trace:

INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: schedule schedule fsnotifysbdelete genericshutdownsuper killanonsuper cleanupmnt taskworkrun doexit dogroupexit

The race window that triggers the iref leak:

Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotifyaddmarklocked(): fsnotifyaddmarklist(): spinlock(conn->lock) add markB(evictable) to list spinunlock(conn->lock) return

/ ---- gap: no lock held ---- /

fsnotifydetachmark(markA): spinlock(markA->lock) clear ATTACHED flag on markA spinunlock(markA->lock) fsnotifyputmark(markA)

fsnotifyrecalcmask(): spinlock(conn->lock) fsnotifyrecalcmask(): / markA skipped: ATTACHED cleared / / only markB(evictable) remains / wantiref = false hasiref = true / not yet cleared / -> HASIREF transitions true -> false -> returns inode pointer spinunlock(conn->lock) / BUG: return value discarded! iput() and fsnotifyputsbwatchedobjects() are never called /

Fix this by deferring the transition true -> false of HASIREF flag from fsnotifyrecalcmask() (Thread A) to fsnotifyputmark() (thread B).

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

KVM: nSVM: Avoid clearing VMCBLBR in vmcb12

svmcopylbrs() always marks VMCBLBR dirty in the destination VMCB. However, nestedsvmvmexit() uses it to copy LBRs to vmcb12, and clearing clean bits in vmcb12 is not architecturally defined.

Move vmcbmarkdirty() to callers and drop it for vmcb12.

This also facilitates incoming refactoring that does not pass the entire VMCB to svmcopylbrs().

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

spi: imx: fix use-after-free on unbind

The SPI subsystem frees the controller and any subsystem allocated driver data as part of deregistration (unless the allocation is device managed).

Take another reference before deregistering the controller so that the driver data is not freed until the driver is done with it.