The Linux Kernel, the operating system core itself.

Security Fix(es):

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

NFSD: Fix ia_size underflow

iattr::iasize is a lofft, which is a signed 64-bit type. NFSv3 and NFSv4 both define file size as an unsigned 64-bit type. Thus there is a range of valid file size values an NFS client can send that is already larger than Linux can handle.

Currently decodefattr4() dumps a full u64 value into iasize. If that value happens to be larger than S64MAX, then iasize underflows. I'm about to fix up the NFSv3 behavior as well, so let's catch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)

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

misc: fastrpc: Fix use-after-free race condition for maps

It is possible that in between calling fastrpcmapget() until map->fl->lock is taken in fastrpcfreemap(), another thread can call fastrpcmaplookup() and get a reference to a map that is about to be deleted.

Rewrite fastrpcmapget() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted.

Fixes this warning: refcountt: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcountwarnsaturate ... Call trace: refcountwarnsaturate [fastrpcmapget inlined] [fastrpcmaplookup inlined] fastrpcmapcreate fastrpcinternalinvoke fastrpcdeviceioctl _arm64sysioctl invoke_syscall(CVE-2022-48872)

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

drm/amd/pm: fix a double-free in sidpminit

When the allocation of adev->pm.dpm.dynstate.vddcdependencyondispclk.entries fails, amdgpufreeextendedpowertable is called to free some fields of adev. However, when the control flow returns to sidpmswinit, it goes to label dpmfailed and calls sidpmfini, which calls amdgpufreeextendedpowertable again and free those fields again. Thus a double-free is triggered.(CVE-2023-52691)

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

f2fs: avoid format-overflow warning

With gcc and W=1 option, there's a warning like this:

fs/f2fs/compress.c: In function ‘f2fsinitpagearraycache’: fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between 1 and 7 bytes into a region of size between 5 and 8 [-Werror=format-overflow=] 1984 | sprintf(slabname, "f2fspagearrayentry-%u:%u", MAJOR(dev), MINOR(dev)); | ^~

String "f2fspagearrayentry-%u:%u" can up to 35. The first "%u" can up to 4 and the second "%u" can up to 7, so total size is "24 + 4 + 7 = 35". slabname's size should be 35 rather than 32.(CVE-2023-52748)

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

usb: gadget: fncm: fix potential NULL ptr deref in ncmbitrate()

In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device.

AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10

The call stack is: ncmclose() -> ncmnotify() -> ncmdonotify() with the crash at: ncmdonotify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)

Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):

// halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usbcdcnotification) 0B 0D 00 79 strh w11, [x8, #6]

// word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8]

// x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usbcompositedev 2A 01 40 F9 ldr x10, [x9]

// loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19]

// x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c]

which seems to line up with ncmdonotify() case NCMNOTIFYSPEED code fragment:

event->wLength = cputole16(8); req->length = NCMSTATUSBYTECOUNT;

/* SPEEDCHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cputole32(ncmbitrate(cdev->gadget));

My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cputole32(ncmbitrate(cdev->gadget)); which calls: ncmbitrate(NULL) which then calls: gadgetissuperspeed(NULL) which reads ((struct usbgadget *)NULL)->maxspeed and hits a panic.

AFAICT, if I'm counting right, the offset of maxspeed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct workstruct)

It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing...(CVE-2023-52894)

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

nilfs2: fix general protection fault in nilfsbtreeinsert()

If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling _nilfsbtreegetblock() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave.

When nilfsbtreeinsert() receives this spurious 'not found' code from nilfsbtreedo_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash:

general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfsbtreegetnonrootnode fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfsbtreeprepareinsert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfsbtreeinsert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfsbmapdoinsert fs/nilfs2/bmap.c:121 [inline] nilfsbmapinsert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfsgetblock+0x414/0x8d0 fs/nilfs2/inode.c:101 _blockwritebeginint+0x54c/0x1a80 fs/buffer.c:1991 _blockwritebegin fs/buffer.c:2041 [inline] blockwritebegin+0x93/0x1e0 fs/buffer.c:2102 nilfswritebegin+0x9c/0x110 fs/nilfs2/inode.c:261 genericperformwrite+0x2e4/0x5e0 mm/filemap.c:3772 _genericfilewriteiter+0x176/0x400 mm/filemap.c:3900 genericfilewriteiter+0xab/0x310 mm/filemap.c:3932 callwriteiter include/linux/fs.h:2186 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x7dc/0xc50 fs/readwrite.c:584 ksyswrite+0x177/0x2a0 fs/readwrite.c:637 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd ... </TASK>

This patch fixes the root cause of this problem by replacing the error code that _nilfsbtreegetblock() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted.

By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfsbmapconvert_error(), and code -EIO will be eventually returned as it should be.(CVE-2023-52900)

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

netfilter: tproxy: bail out if IP has been disabled on the device

syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nftproxyladdr4+0xb7/0x340 net/ipv4/netfilter/nftproxyipv4.c:62 Call Trace: nfttproxyevalv4 net/netfilter/nfttproxy.c:56 [inline] nfttproxyeval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168

_indevgetrcu() can return NULL, so check for this.(CVE-2024-36270)

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

nfc: llcp: fix nfcllcpsetsockopt() unsafe copies

syzbot reported unsafe calls to copyfromsockptr() [1]

Use copysafefrom_sockptr() instead.

[1]

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078

CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 copyfromsockptroffset include/linux/sockptr.h:49 [inline] copyfromsockptr include/linux/sockptr.h:55 [inline] nfcllcpsetsockopt+0x6c2/0x850 net/nfc/llcpsock.c:255 dosocksetsockopt+0x3b1/0x720 net/socket.c:2311 _syssetsockopt+0x1ae/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfd/0x240 entrySYSCALL64afterhwframe+0x6d/0x75 RIP: 0033:0x7f7fac07fd89 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIGRAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89 RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)

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

wifi: ar5523: enable proper endpoint verification

Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it.

Fix the issue by checking for the existence of all proper endpoints with their according types intact.

Sadly, this patch has not been tested on real hardware.

[1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usbsubmiturb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523cmdread drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523hostavailable drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usbprobeinterface+0x30f/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:560 [inline] reallyprobe+0x249/0xb90 drivers/base/dd.c:639 _driverprobedevice+0x1df/0x4d0 drivers/base/dd.c:778 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:808 _deviceattachdriver+0x1d4/0x2e0 drivers/base/dd.c:936 busforeachdrv+0x163/0x1e0 drivers/base/bus.c:427 _deviceattach+0x1e4/0x530 drivers/base/dd.c:1008 busprobedevice+0x1e8/0x2a0 drivers/base/bus.c:487 deviceadd+0xbd9/0x1e90 drivers/base/core.c:3517 usbsetconfiguration+0x101d/0x1900 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xbe/0x100 drivers/usb/core/generic.c:238 usbprobedevice+0xd8/0x2c0 drivers/usb/core/driver.c:293 calldriverprobe drivers/base/dd.c:560 [inline] reallyprobe+0x249/0xb90 drivers/base/dd.c:639 _driverprobedevice+0x1df/0x4d0 drivers/base/dd.c:778 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:808 _deviceattachdriver+0x1d4/0x2e0 drivers/base/dd.c:936 busforeachdrv+0x163/0x1e0 drivers/base/bus.c:427 _deviceattach+0x1e4/0x530 drivers/base/dd.c:1008 busprobedevice+0x1e8/0x2a0 drivers/base/bus.c:487 deviceadd+0xbd9/0x1e90 drivers/base/core.c:3517 usbnewdevice.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hubportconnect drivers/usb/core/hub.c:5353 [inline] hubportconnectchange drivers/usb/core/hub.c:5497 [inline] portevent drivers/usb/core/hub.c:5653 [inline] hubevent+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 processonework+0x9bf/0x1710 kernel/workqueue.c:2289 workerthread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306 </TASK>(CVE-2024-38565)

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

jfs: don't walk off the end of ealist

Add a check before visiting the members of ea to make sure each ea stays within the ealist.(CVE-2024-41017)

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

hfsplus: fix uninit-value in copy_name

[syzbot reported] BUG: KMSAN: uninit-value in sizedstrscpy+0xc4/0x160 sizedstrscpy+0xc4/0x160 copyname+0x2af/0x320 fs/hfsplus/xattr.c:411 hfspluslistxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfslistxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 pathlistxattr fs/xattr.c:864 [inline] _dosyslistxattr fs/xattr.c:876 [inline] _sesyslistxattr fs/xattr.c:873 [inline] _x64syslistxattr+0x16b/0x2f0 fs/xattr.c:873 x64syscall+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls64.h:195 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:3877 [inline] slaballocnode mm/slub.c:3918 [inline] kmalloctrace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfspluslistxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfslistxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 pathlistxattr fs/xattr.c:864 [inline] _dosyslistxattr fs/xattr.c:876 [inline] _sesyslistxattr fs/xattr.c:873 [inline] _x64syslistxattr+0x16b/0x2f0 fs/xattr.c:873 x64syscall+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls64.h:195 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)

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

ata: libata-core: Fix null pointer dereference on error

If the ataportalloc() call in atahostalloc() fails, atahostrelease() will get called.

However, the code in atahostrelease() tries to free ata_port struct members unconditionally, which can lead to the following:

BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:atahostrelease.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? _diebody.cold+0x19/0x27 ? pagefaultoops+0x15a/0x2f0 ? excpagefault+0x7e/0x180 ? asmexcpagefault+0x26/0x30 ? atahostrelease.cold+0x2f/0x6e [libata] ? atahostrelease.cold+0x2f/0x6e [libata] releasenodes+0x35/0xb0 devresreleasegroup+0x113/0x140 atahostalloc+0xed/0x120 [libata] atahostallocpinfo+0x14/0xa0 [libata] ahciinit_one+0x6c9/0xd20 [ahci]

Do not access ata_port struct members unconditionally.(CVE-2024-41098)

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

nilfs2: add missing check for inode numbers on directory entries

Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lruaddfn().

As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfsevictinode(), which is called from iput(), tries to delete that inode (ifile inode in this case).

The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking.

Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages.

Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis.(CVE-2024-42104)

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

drm/amd/display: Skip finding free audio for unknown engine_id

[WHY] ENGINEIDUNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio.

[HOW] Skip and return NULL.

This fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)

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

kobjectuevent: Fix OOB access within zapmodalias_env()

zapmodaliasenv() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)

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

x86/mm: Fix pticlonepgtable() alignment assumption

Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then

DF from the stack guard.

It turned out that pticlonepgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386.

These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text?

Use the correct increment form for addr to avoid alignment assumptions.(CVE-2024-44965)

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

mptcp: pm: avoid possible UaF when selecting endp

selectlocaladdress() and selectsignaladdress() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free.

A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with.(CVE-2024-44974)

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

net: hns3: fix a deadlock problem when config TC during resetting

When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napidisable() napidisable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napienable() │ ▼ UINIT: netifnapidel() │ ▼ ...... │ ▼ INIT: netifnapiadd() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napienable()(skip) ...... │ │ ▼ ▼ ...... napi_disable()

In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)

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

gtp: pull network headers in gtpdevxmit()

syzbot/KMSAN reported use of uninit-value in getdevxmit() [1]

We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them.

Use pskbinetmay_pull() to fix this issue.

[1] BUG: KMSAN: uninit-value in ipv6pdpfind drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtpbuildskbip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtpdevxmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6pdpfind drivers/net/gtp.c:220 [inline] gtpbuildskbip6 drivers/net/gtp.c:1229 [inline] gtpdevxmit+0x1424/0x2540 drivers/net/gtp.c:1281 _netdevstartxmit include/linux/netdevice.h:4913 [inline] netdevstartxmit include/linux/netdevice.h:4922 [inline] xmitone net/core/dev.c:3580 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3596 _devqueuexmit+0x358c/0x5610 net/core/dev.c:4423 devqueuexmit include/linux/netdevice.h:3105 [inline] packetxmit+0x9c/0x6c0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3145 [inline] packetsendmsg+0x90e3/0xa3a0 net/packet/afpacket.c:3177 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 _syssendto+0x685/0x830 net/socket.c:2204 _dosyssendto net/socket.c:2216 [inline] _sesyssendto net/socket.c:2212 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2212 x64syscall+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls64.h:45 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:3994 [inline] slaballocnode mm/slub.c:4037 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4080 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:583 _allocskb+0x363/0x7b0 net/core/skbuff.c:674 allocskb include/linux/skbuff.h:1320 [inline] allocskbwithfrags+0xc8/0xbf0 net/core/skbuff.c:6526 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2815 packetallocskb net/packet/afpacket.c:2994 [inline] packetsnd net/packet/afpacket.c:3088 [inline] packetsendmsg+0x749c/0xa3a0 net/packet/afpacket.c:3177 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 _syssendto+0x685/0x830 net/socket.c:2204 _dosyssendto net/socket.c:2216 [inline] _sesyssendto net/socket.c:2212 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2212 x64syscall+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls64.h:45 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)

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

vfs: Don't evict inode under the inode lru traversing context

The inode reclaiming process(See function pruneicachesb) collects all reclaimable inodes and mark them with IFREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function findinodefast), then the reclaiming process destroy the inodes by function disposelist(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen.

Case 1: In function ext4evictinode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this:

1. File A has inode ireg and an ea inode iea
2. getfattr(A, xattrbuf) // iea is added into lru // lru->i_ea

3. Then, following three processes running like this:

   PA PB echo 2 > /proc/sys/vm/dropcaches shrinkslab prunedcachesb // ireg is added into lru, lru->iea->ireg pruneicachesb listlruwalkone inodelruisolate iea->istate |= IFREEING // set inode state inodelruisolate _iget(ireg) spinunlock(&ireg->ilock) spinunlock(lrulock) rm file A ireg->nlink = 0 iput(ireg) // ireg->nlink is 0, do evict ext4evictinode ext4xattrdeleteinode ext4xattrinodedecrefall ext4xattrinodeiget ext4iget(iea->iino) igetlocked findinodefast _waitonfreeinginode(iea) ----→ AA deadlock disposelist // cannot be executed by pruneicachesb wakeupbit(&iea->istate)

Case 2: In deleted inode writing function ubifsjnlwriteinode(), file deleting process holds BASEHD's wbuf->iomutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following:

1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr.
2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa

3. Then, following three processes running like this:

      PA                PB                        PC
              echo 2 > /proc/sys/vm/drop_caches
               shrink_slab
                prune_dcache_sb
                // ib and ia are added into lru, lru->ixa->ib->ia
                prune_icache_sb
                 list_lru_walk_one
                  inode_lru_isolate
                   ixa->i_state |= I_FREEING // set inode state
                  inode_lru_isolate
                   __iget(ib)
                   spin_unlock(&ib->i_lock)
                   spin_unlock(lru_lock)
                                                 rm file B
                                                  ib->nlink = 0
   

   rm file A iput(ia) ubifsevictinode(ia) ubifsjnldeleteinode(ia) ubifsjnlwriteinode(ia) makereservation(BASEHD) // Lock wbuf->iomutex ubifsiget(ixa->iino) igetlocked findinodefast _waitonfreeinginode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifsevictinode | ubifsjnldeleteinode(ib) ↓ ubifsjnlwriteinode ABBA deadlock ←-----makereservation(BASEHD) disposelist // cannot be executed by pruneicachesb wakeupbit(&ixa->istate)

Fix the possible deadlock by using new inode state flag ILRUISOLATING to pin the inode in memory while inodelruisolate( ---truncated---(CVE-2024-45003)

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

mmc: mmc_test: Fix NULL dereference on allocation failure

If the "test->highmem = allocpages()" allocation fails then calling _free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success.(CVE-2024-45028)

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

drm/amd/display: Skip wbsclsetscaler_filter if filter is null

Callers can pass null in filter (i.e. from returned from the function wbsclgetfiltercoeffs16p) and a null check is added to ensure that is not the case.

This fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)

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

drm/amdgpu: fix ucode out-of-bounds read warning

Clear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)

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

drm/amd/pm: fix the Out-of-bounds read warning

using index i - 1U may beyond element index for mc_data[] when i = 0.(CVE-2024-46731)

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

btrfs: fix qgroup reserve leaks in cowfilerange

In the buffered write path, the dirty page owns the qgroup reserve until it creates an ordered_extent.

Therefore, any errors that occur before the orderedextent is created must free that reservation, or else the space is leaked. The fstest generic/475 exercises various IO error paths, and is able to trigger errors in cowfile_range where we fail to get to allocating the ordered extent. Note that because we do clear delalloc, we are likely to remove the inode from the delalloc list, so the inodes/pages to not have invalidate/launder called on them in the commit abort path.

This results in failures at the unmount stage of the test that look like:

BTRFS: error (device dm-8 state EA) in cleanuptransaction:2018: errno=-5 IO failure BTRFS: error (device dm-8 state EA) in btrfsreplacefileextents:2416: errno=-5 IO failure BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 closectree+0x222/0x4d0 [btrfs] Modules linked in: btrfs blake2bgeneric libcrc32c xor zstdcompress raid6pq CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W 6.10.0-rc7-gab56fde445b8 #21 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:closectree+0x222/0x4d0 [btrfs] RSP: 0018:ffffb4465283be00 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8 RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0 Call Trace: <TASK> ? closectree+0x222/0x4d0 [btrfs] ? _warn.cold+0x8e/0xea ? closectree+0x222/0x4d0 [btrfs] ? reportbug+0xff/0x140 ? handlebug+0x3b/0x70 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? closectree+0x222/0x4d0 [btrfs] genericshutdownsuper+0x70/0x160 killanonsuper+0x11/0x40 btrfskillsuper+0x11/0x20 [btrfs] deactivatelockedsuper+0x2e/0xa0 cleanupmnt+0xb5/0x150 taskworkrun+0x57/0x80 syscallexittousermode+0x121/0x130 dosyscall64+0xab/0x1a0 entrySYSCALL64after_hwframe+0x77/0x7f RIP: 0033:0x7f916847a887 ---[ end trace 0000000000000000 ]--- BTRFS error (device dm-8 state EA): qgroup reserved space leaked

Cases 2 and 3 in the outreserve path both pertain to this type of leak and must free the reserved qgroup data. Because it is already an error path, I opted not to handle the possible errors in btrfsfreeqgroupdata.(CVE-2024-46733)

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

Squashfs: sanity check symbolic link size

Syzkiller reports a "KMSAN: uninit-value in pick_link" bug.

This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk.

The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events:

1. squashfsreadinode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.

2. Later squashfssymlinkread_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.

3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.

This patch adds a sanity check which checks that the symbolic link size is not larger than expected.

--

V2: fix spelling mistake.(CVE-2024-46744)

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

Input: uinput - reject requests with unreasonable number of slots

When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in inputmtinit_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request.

Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)

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

HID: cougar: fix slab-out-of-bounds Read in cougarreportfixup

report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it(CVE-2024-46747)

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

btrfs: don't BUGON() when 0 reference count at btrfslookupextentinfo()

Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message.(CVE-2024-46751)

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

btrfs: replace BUGON() with error handling at updaterefforcow()

Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory).(CVE-2024-46752)

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

userfaultfd: fix checks for huge PMDs

Patch series "userfaultfd: fix races around pmdtranshuge() check", v2.

The pmdtranshuge() code in mfill_atomic() is wrong in three different ways depending on kernel version:

1. The pmdtranshuge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case).
2. As pointed out by Qi Zheng, pmdtranshuge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into trytomigrate()) against UFFDIOZEROPAGE - on my x86 VM, that causes a kernel oops in ptlockptr().
3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUGON() checks in mfillatomic() are just wrong.

I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2.

This patch (of 2):

This fixes two issues.

I discovered that the following race can occur:

mfillatomic other thread ============ ============ <zap PMD> pmdpgetlockless() [reads none pmd] <bail if transhuge> <if none:> <pagefault creates transhuge zeropage> _ptealloc [no-op] <zap PMD> <bail if pmdtranshuge(dst_pmd)> BUG_ON(pmd_none(dst_pmd))

I have experimentally verified this in a kernel with extra mdelay() calls; the BUGON(pmdnone(*dst_pmd)) triggers.

On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pteoffsetmaplock to fail"), this can't lead to anything worse than a BUGON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table.

The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmdtranshuge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs).

On <=6.4, this is worse than the first issue: If mfillatomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pteoffsetmaplock(), which assumes that the PMD points to a page table.

Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different).

If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table.

As part of fixing these issues, get rid of the check for pmdtranshuge() before _ptealloc() - that's redundant, we're going to have to check for that after the _ptealloc() anyway.

Backport note: pmdpgetlockless() is pmdreadatomic() in older kernels.(CVE-2024-46787)