The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

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:

Input: MT - limit max slots

syzbot is reporting too large allocation at inputmtinitslots(), for numslots is supplied from userspace using ioctl(UIDEVCREATE).

Since nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)

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

fix bitmap corruption on closerange() with CLOSERANGE_UNSHARE

copyfdbitmaps(new, old, count) is expected to copy the first count/BITSPERLONG bits from old->fullfdsbits[] and fill the rest with zeroes. What it does is copying enough words (BITSTOLONGS(count/BITSPERLONG)), then memsets the rest. That works fine, if all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied.

For most of the callers that is true - expandfdtable() has count equal to old->maxfds, so there's no open descriptors past count, let alone fully occupied words in ->openfds[], which is what bits in ->fullfds_bits[] correspond to.

The other caller (dupfd()) passes sanefdtablesize(oldfdt, maxfds), which is the smallest multiple of BITSPERLONG that covers all opened descriptors below maxfds. In the common case (copying on fork()) maxfds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expandfdtable() is safe.

Unfortunately, there is a case where maxfds is less than that and where we might, indeed, end up with junk in ->fullfdsbits[] - closerange(from, to, CLOSERANGEUNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONEFILES, get all descriptors in range 0..127 open, then closerange(64, ~0U, CLOSERANGEUNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open.

The minimally invasive fix would be to deal with that in dupfd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copyfd_bitmaps() first.

• new helper: bitmapcopyandexpand(to, from, bitsto_copy, size).
• make copyfdbitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITSPERLONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITSPERLONG for the large ones, so it'll generate plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/closerangetest.c(CVE-2024-45025)

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/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:

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:

wifi: mwifiex: Do not return unused priv in mwifiexgetprivbyid()

mwifiexgetprivbyid() returns the priv pointer corresponding to the bssnum and bsstype, but without checking if the priv is actually currently in use. Unused priv pointers do not have a wiphy attached to them which can lead to NULL pointer dereferences further down the callstack. Fix this by returning only used priv pointers which have priv->bssmode set to something else than NL80211IFTYPE_UNSPECIFIED.

Said NULL pointer dereference happened when an Accesspoint was started with wpa_supplicant -i mlan0 with this config:

network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" }

When waiting for the AP to be established, interrupting wpa_supplicant with <ctrl-c> and starting it again this happens:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140 | 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, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000 | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: caamjr caamhashdesc spidev caamalgdesc cryptoengine authenc libdes mwifiexsdio +mwifiex crct10difce cdcacm onboardusbhub fslimx8ddrperf imx8mddrc rtcds1307 lm75 rtcsnvs +imxsdma caam imx8mmthermal spiimx error imxcpufreqdt fuse iptables xtables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18 | Hardware name: somemachine (DT) | Workqueue: events sdioirqwork | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiexgetcfp+0xd8/0x15c [mwifiex] | lr : mwifiexgetcfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157 | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Call trace: | mwifiexgetcfp+0xd8/0x15c [mwifiex] | mwifiexparsesingleresponsebuf+0x1d0/0x504 [mwifiex] | mwifiexhandleeventextscanreport+0x19c/0x2f8 [mwifiex] | mwifiexprocessstaevent+0x298/0xf0c [mwifiex] | mwifiexprocessevent+0x110/0x238 [mwifiex] | mwifiexmainprocess+0x428/0xa44 [mwifiex] | mwifiexsdiointerrupt+0x64/0x12c [mwifiexsdio] | processsdiopendingirqs+0x64/0x1b8 | sdioirqwork+0x4c/0x7c | processonework+0x148/0x2a0 | workerthread+0x2fc/0x40c | kthread+0x110/0x114 | retfrom_fork+0x10/0x20 | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ end trace 0000000000000000 ]---(CVE-2024-46755)

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

hwmon: (adc128d818) Fix underflows seen when writing limit attributes

DIVROUNDCLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clampval() and DIVROUND_CLOSEST() operations.(CVE-2024-46759)

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

sch/netem: fix use after free in netem_dequeue

If netemdequeue() enqueues packet to inner qdisc and that qdisc returns _NETXMITSTOLEN. The packet is dropped but qdisctreereduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails")

Commands to trigger KASAN UaF:

ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF(CVE-2024-46800)