The Linux Kernel, the operating system core itself.

Security Fix(es):

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

afunix: Update unixsk(sk)->oobskb under skreceive_queue lock.

Billy Jheng Bing-Jhong reported a race between _unixgc() and queue_oob().

_unixgc() tries to garbage-collect close()d inflight sockets, and then if the socket has MSGOOB in unixsk(sk)->oob_skb, GC will drop the reference and set NULL to it locklessly.

However, the peer socket still can send MSGOOB message and queueoob() can update unixsk(sk)->oobskb concurrently, leading NULL pointer dereference. [0]

To fix the issue, let's update unixsk(sk)->oobskb under the skreceivequeue's lock and take it everywhere we touch oob_skb.

Note that we defer kfreeskb() in manageoob() to silence lockdep false-positive (See [1]).

PF: supervisor write access in kernel mode PF: errorcode(0x0002) - not-present page PGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events delayedfput RIP: 0010:skbdequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847) Code: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 <48> 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc cc RSP: 0018:ffffc900001bfd48 EFLAGS: 00000002 RAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9 RDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00 RBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00 R13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80 FS: 0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <TASK> unixreleasesock (net/unix/afunix.c:654) unixrelease (net/unix/afunix.c:1050) _sockrelease (net/socket.c:660) sockclose (net/socket.c:1423) _fput (fs/filetable.c:423) delayedfput (fs/filetable.c:444 (discriminator 3)) processonework (kernel/workqueue.c:3259) workerthread (kernel/workqueue.c:3329 kernel/workqueue.c:3416) kthread (kernel/kthread.c:388) retfromfork (arch/x86/kernel/process.c:153) retfromforkasm (arch/x86/entry/entry64.S:257) </TASK> Modules linked in: CR2: 0000000000000008(CVE-2024-36972)

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

net: do not leave a dangling sk pointer, when socket creation fails

It is possible to trigger a use-after-free by: * attaching an fentry probe to _sockrelease() and the probe calling the bpfgetsocket_cookie() helper * running traceroute -I 1.1.1.1 on a freshly booted VM

A KASAN enabled kernel will log something like below (decoded and stripped):

BUG: KASAN: slab-use-after-free in _sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299

CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:117 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasanreport (mm/kasan/report.c:603) ? _sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasancheckrange (mm/kasan/generic.c:183 mm/kasan/generic.c:189) _sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) bpfgetsocketptrcookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sockdiag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpfprog875642cf11f1d139sockrelease+0x6e/0x8e bpftrampoline6442506592+0x47/0xaf _sockrelease (net/socket.c:652) _sockcreate (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) _kasanslaballoc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmemcacheallocnoprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) skprotalloc (net/core/sock.c:2075) skalloc (net/core/sock.c:2134) inetcreate (net/ipv4/afinet.c:327 net/ipv4/afinet.c:252) _sockcreate (net/socket.c:1572) _syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) _x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Freed by task 299 on cpu 2 at 78.328502s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasansavefreeinfo (mm/kasan/generic.c:582) poisonslabobject (mm/kasan/common.c:242) _kasanslabfree (mm/kasan/common.c:256) kmemcachefree (mm/slub.c:4437 mm/slub.c:4511) _skdestruct (net/core/sock.c:2117 net/core/sock.c:2208) inetcreate (net/ipv4/afinet.c:397 net/ipv4/afinet.c:252) _sockcreate (net/socket.c:1572) _syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) _x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

Fix this by clearing the struct socket reference in skcommonrelease() to cover all protocol families create functions, which may already attached the reference to the sk object with sockinitdata().(CVE-2024-40954)

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

netns: Make getnetns() handle zero refcount net

Syzkaller hit a warning: refcountt: addition on 0; use-after-free. WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcountwarnsaturate+0xdf/0x1d0 Modules linked in: CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:refcountwarnsaturate+0xdf/0x1d0 Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1 RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001 RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139 R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4 R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040 FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? showregs+0xa3/0xc0 ? _warn+0xa5/0x1c0 ? refcountwarnsaturate+0xdf/0x1d0 ? reportbug+0x1fc/0x2d0 ? refcountwarnsaturate+0xdf/0x1d0 ? handlebug+0xa1/0x110 ? excinvalidop+0x3c/0xb0 ? asmexcinvalidop+0x1f/0x30 ? _warnprintk+0xcc/0x140 ? _warnprintk+0xd5/0x140 ? refcountwarnsaturate+0xdf/0x1d0 getnetns+0xa4/0xc0 ? _pfxgetnetns+0x10/0x10 openrelatedns+0x5a/0x130 _tunchrioctl+0x1616/0x2370 ? _sanitizercovtraceswitch+0x58/0xa0 ? _sanitizercovtraceconstcmp2+0x1c/0x30 ? _pfxtunchrioctl+0x10/0x10 tunchrioctl+0x2f/0x40 _x64sysioctl+0x11b/0x160 x64syscall+0x1211/0x20d0 dosyscall64+0x9e/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f5b28f165d7 Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8 RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7 RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003 RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0 R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730 R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: kernel: paniconwarn set ...

This is trigger as below: ns0 ns1 tunsetiff() //dev is tun0 tun->dev = dev //ip link set tun0 netns ns1 putnet() //ref is 0 _tunchrioctl() //TUNGETDEVNETNS net = devnet(tun->dev); openrelatedns(&net->ns, getnetns); //ns1 getnetns() getnet() //addition on 0

Use maybegetnet() in getnetns in case net's ref is zero to fix this(CVE-2024-40958)

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

cachefiles: fix slab-use-after-free in cachefileswithdrawcookie()

We got the following issue in our fault injection stress test:

================================================================== BUG: KASAN: slab-use-after-free in cachefileswithdrawcookie+0x4d9/0x600 Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109

CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566 Call Trace: <TASK> kasanreport+0x93/0xc0 cachefileswithdrawcookie+0x4d9/0x600 fscachecookiestatemachine+0x5c8/0x1230 fscachecookieworker+0x91/0x1c0 processonework+0x7fa/0x1800 [...]

Allocated by task 117: kmalloctrace+0x1b3/0x3c0 cachefilesacquirevolume+0xf3/0x9c0 fscachecreatevolumework+0x97/0x150 processonework+0x7fa/0x1800 [...]

Freed by task 120301: kfree+0xf1/0x2c0 cachefileswithdrawcache+0x3fa/0x920 cachefilesputunbindpincount+0x1f6/0x250 cachefilesdaemonrelease+0x13b/0x290 _fput+0x204/0xa00 taskworkrun+0x139/0x230 do_exit+0x87a/0x29b0

[...]

Following is the process that triggers the issue:

p1 | p2

                          fscache_begin_lookup
                           fscache_begin_volume_access
                            fscache_cache_is_live(fscache_cache)

cachefilesdaemonrelease cachefilesputunbindpincount cachefilesdaemonunbind cachefileswithdrawcache fscachewithdrawcache fscachesetcachestate(cache, FSCACHECACHEISWITHDRAWN); cachefileswithdrawobjects(cache) fscachewaitforobjects(fscache) atomicread(&fscachecache->objectcount) == 0 fscacheperformlookup cachefileslookupcookie cachefilesallocobject refcountset(&object->ref, 1); object->volume = volume fscachecountobject(vcookie->cache); atomicinc(&fscachecache->objectcount) cachefileswithdrawvolumes cachefileswithdrawvolume fscachewithdrawvolume _cachefilesfreevolume kfree(cachefilesvolume) fscachecookiestatemachine cachefileswithdrawcookie cache = object->volume->cache; // cachefiles_volume UAF !!!

After setting FSCACHECACHEISWITHDRAWN, wait for all the cookie lookups to complete first, and then wait for fscachecache->objectcount == 0 to avoid the cookie exiting after the volume has been freed and triggering the above issue. Therefore call fscachewithdrawvolume() before calling cachefileswithdraw_objects().

This way, after setting FSCACHECACHEISWITHDRAWN, only the following two cases will occur: 1) fscachebeginlookup fails in fscachebeginvolumeaccess(). 2) fscachewithdrawvolume() will ensure that fscachecountobject() has been executed before calling fscachewaitfor_objects().(CVE-2024-41057)

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

scsi: mpi3mr: Sanitise num_phys

Information is stored in mrsasport->phy_mask, values larger then size of this field shouldn't be allowed.(CVE-2024-42159)

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

vhost/vsock: always initialize seqpacket_allow

There are two issues around seqpacketallow: 1. seqpacketallow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIOVSOCKFSEQPACKET is set and then cleared, then seqpacketallow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this).

To fix: - initialize seqpacketallow after allocation - set it unconditionally in setfeatures(CVE-2024-43873)

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

drm/amdgpu: Validate TA binary size

Add TA binary size validation to avoid OOB write.

(cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442)(CVE-2024-44977)

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

netfilter: flowtable: validate vlan header

Ensure there is sufficient room to access the protocol field of the VLAN header, validate it once before the flowtable lookup.

===================================================== BUG: KMSAN: uninit-value in nfflowoffloadinethook+0x45a/0x5f0 net/netfilter/nfflowtableinet.c:32 nfflowoffloadinethook+0x45a/0x5f0 net/netfilter/nfflowtableinet.c:32 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhookingress include/linux/netfilternetdev.h:34 [inline] nf_ingress net/core/dev.c:5440 inline

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

atm: idt77252: prevent use after free in dequeue_rx()

We can't dereference "skb" after calling vcc->push() because the skb is released.(CVE-2024-44998)

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

HID: amdsfh: free driverdata after destroying hid device

HID driver callbacks aren't called anymore once hiddestroydevice() has been called. Hence, hid driverdata should be freed only after the hiddestroydevice() function returned as driverdata is used in several callbacks.

I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling KASAN to debug memory allocation, I got this output:

[ 13.050438] ================================================================== [ 13.054060] BUG: KASAN: slab-use-after-free in amdsfhgetreport+0x3ec/0x530 [amdsfh] [ 13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3 [ 13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479

[ 13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0 [ 13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024 [ 13.067860] Call Trace: [ 13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8 [ 13.071486] <TASK> [ 13.071492] dumpstacklvl+0x5d/0x80 [ 13.074870] sndhdaintel 0000:33:00.6: enabling device (0000 -> 0002) [ 13.078296] ? amdsfhgetreport+0x3ec/0x530 [amdsfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.082199] printreport+0x174/0x505 [ 13.085776] ? pfxrawspinlockirqsave+0x10/0x10 [ 13.089367] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 13.093255] ? amdsfhgetreport+0x3ec/0x530 [amdsfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.097464] kasanreport+0xc8/0x150 [ 13.101461] ? amdsfhgetreport+0x3ec/0x530 [amdsfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.105802] amdsfhgetreport+0x3ec/0x530 [amdsfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.110303] amdtphidrequest+0xb8/0x110 [amdsfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.114879] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 13.119450] sensorhubgetfeature+0x1d3/0x540 [hidsensorhub 3f13be3016ff415bea03008d45d99da837ee3082] [ 13.124097] hidsensorparsecommonattributes+0x4d0/0xad0 [hidsensoriiocommon c3a5cbe93969c28b122609768bbe23efe52eb8f5] [ 13.127404] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 13.131925] ? pfxhidsensorparsecommonattributes+0x10/0x10 [hidsensoriiocommon c3a5cbe93969c28b122609768bbe23efe52eb8f5] [ 13.136455] ? _rawspinlockirqsave+0x96/0xf0 [ 13.140197] ? _pfxrawspinlockirqsave+0x10/0x10 [ 13.143602] ? devmiiodevicealloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b] [ 13.147234] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 13.150446] ? devmaddaction+0x167/0x1d0 [ 13.155061] hidgyro3dprobe+0x120/0x7f0 [hidsensorgyro3d 63da36a143b775846ab2dbb86c343b401b5e3172] [ 13.158581] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 13.161814] platformprobe+0xa2/0x150 [ 13.165029] reallyprobe+0x1e3/0x8a0 [ 13.168243] _driverprobedevice+0x18c/0x370 [ 13.171500] driverprobedevice+0x4a/0x120 [ 13.175000] _driverattach+0x190/0x4a0 [ 13.178521] ? _pfxdriverattach+0x10/0x10 [ 13.181771] busforeachdev+0x106/0x180 [ 13.185033] ? pfxrawspinlock+0x10/0x10 [ 13.188229] ? _pfxbusforeachdev+0x10/0x10 [ 13.191446] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 13.194382] busadddriver+0x29e/0x4d0 [ 13.197328] driverregister+0x1a5/0x360 [ 13.200283] ? _pfxhidgyro3dplatformdriverinit+0x10/0x10 [hidsensorgyro3d 63da36a143b775846ab2dbb86c343b401b5e3172] [ 13.203362] dooneinitcall+0xa7/0x380 [ 13.206432] ? _pfxdooneinitcall+0x10/0x10 [ 13.210175] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 13.213211] ? kasanunpoison+0x44/0x70 [ 13.216688] doinit_module+0x238/0x750 [ 13.2196 ---truncated---(CVE-2024-46746)

In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.(CVE-2024-49853)

In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platformdeviceregister() errors x86androidtabletremove() frees the pdevs[] array, so it should not be used after calling x86androidtabletremove(). When platformdeviceregister() fails, store the pdevs[x] PTRERR() value into the local ret variable before calling x86androidtabletremove() to avoid using pdevs[] after it has been freed.(CVE-2024-49986)

(CVE-2024-50121)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on scosocktimeout conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.(CVE-2024-50125)

In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayedwork on cachectr error An unexpected WARNON from flushwork() may occur when cache creation fails, caused by destroying the uninitialized delayedwork waker in the error path of cachecreate(). For example, the warning appears on the superblock checksum error. Reproduce steps: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 _flushwork+0x5d4/0x890 Fix by pulling out the canceldelayedworksync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dmresume and dmdestroy (commit 6a459d8edbdb ("dm cache: Fix UAF in destroy()")) as cachedtr is not changed.(CVE-2024-50280)

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: fix fault at system suspend if device was already runtime suspended If the device was already runtime suspended then during system suspend we cannot access the device registers else it will crash. Also we cannot access any registers after dwc3coreexit() on some platforms so move the dwc3enablesusphy() call to the top.(CVE-2024-53070)

In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIGNETNSREFCNTTRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcpwritetimerhandler()."). Note that we need to move putnet() from cifsputtcpsession() to cleandemultiplexinfo(); otherwise, _sockcreate() still could touch a freed netns while cifsd tries to reconnect from cifsdemultiplexthread(). Also, maybegetnet() cannot be put just before _sockcreate() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: clsbpf schingress nlsutf8 cifs cifsarc4 cifsmd4 dnsresolver tcpdiag inetdiag veth xtstate xtconnmark nfconntracknetlink xtnat xtstatistic xtMASQUERADE xtmark xtaddrtype iptREJECT nfrejectipv4 nftchainnat nfnat xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment nftcompat nftables nfnetlink overlay nlsascii nlscp437 sunrpc vfat fat aesceblk aescecipher ghashce sm4cecipher sm4 sm3ce sm3 sha3ce sha512ce sha512arm64 sha1ce ena button schfqcodel loop fuse configfs dmisysfs sha2ce sha256arm64 dmmirror dmregionhash dmlog dmmod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fibruleslookup+0x44/0x238 lr : _fiblookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fibruleslookup+0x44/0x238 _fiblookup+0x64/0xbc iprouteoutputkeyhashrcu+0x2c4/0x398 iprouteoutputkeyhash+0x60/0x8c tcpv4connect+0x290/0x488 _inetstreamconnect+0x108/0x3d0 inetstreamconnect+0x50/0x78 kernelconnect+0x6c/0xac genericipconne ---truncated---(CVE-2024-53095)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpudmupdatefreesynccaps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amdvsdbblock size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)(CVE-2024-53108)

In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtcstate. Fix warning: drivers/gpu/drm/rockchip/rockchipdrmvop.c:1096 vopplaneatomicasync_check() warn: variable dereferenced before check 'state' (see line 1077)(CVE-2024-53129)

In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpiofile := ALGN(4) + cpioheader + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 cnamesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's doname() path handler assumes a zero-terminated path at @collected, passing it directly to filpopen() / initmkdir() / initmknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfstestfnameoverrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @outbuf in _gunzip(), rather than the initrdstart+initrdsize block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfstestfnameoverrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in dosymlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.(CVE-2024-53142)