OESA-2024-2535

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIGDEBUGKOBJECTRELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobjectrelease, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobjectrelease, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobjectrelease, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typecaltmoderelease+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobjectdelayedcleanup [ 46.616446] Call Trace: [ 46.616648] <TASK> [ 46.616820] dumpstacklvl+0x5b/0x7c [ 46.617112] ? typecaltmoderelease+0x38/0x129 [ 46.617470] printreport+0x14c/0x49e [ 46.617769] ? rcureadunlocksched+0x56/0x69 [ 46.618117] ? _virtaddrvalid+0x19a/0x1ab [ 46.618456] ? kmemcachedebugflags+0xc/0x1d [ 46.618807] ? typecaltmoderelease+0x38/0x129 [ 46.619161] kasanreport+0x8d/0xb4 [ 46.619447] ? typecaltmoderelease+0x38/0x129 [ 46.619809] ? processscheduledworks+0x3cb/0x85f [ 46.620185] typecaltmoderelease+0x38/0x129 [ 46.620537] ? processscheduledworks+0x3cb/0x85f [ 46.620907] devicerelease+0xaf/0xf2 [ 46.621206] kobjectdelayedcleanup+0x13b/0x17a [ 46.621584] processscheduledworks+0x4f6/0x85f [ 46.621955] ? _pfxprocessscheduledworks+0x10/0x10 [ 46.622353] ? hlockclass+0x31/0x9a [ 46.622647] ? lockacquired+0x361/0x3c3 [ 46.622956] ? movelinkedworks+0x46/0x7d [ 46.623277] workerthread+0x1ce/0x291 [ 46.623582] ? _kthreadparkme+0xc8/0xdf [ 46.623900] ? _pfxworkerthread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? _pfxkthread+0x10/0x10 [ 46.625015] retfromfork+0x20/0x40 [ 46.625268] ? _pfxkthread+0x10/0x10 [ 46.625532] retfromforkasm+0x1a/0x30 [ 46.625805] </TASK> [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasansavestack+0x24/0x44 [ 46.626555] kasansavetrack+0x14/0x2d [ 46.626811] _kasankmalloc+0x3f/0x4d [ 46.627049] _kmallocnoprof+0x1bf/0x1f0 [ 46.627362] typecregisterport+0x23/0x491 [ 46.627698] crostypecprobe+0x634/0xbb6 [ 46.628026] platformprobe+0x47/0x8c [ 46.628311] reallyprobe+0x20a/0x47d [ 46.628605] devicedriverattach+0x39/0x72 [ 46.628940] bindstore+0x87/0xd7 [ 46.629213] kernfsfopwriteiter+0x1aa/0x218 [ 46.629574] vfswrite+0x1d6/0x29b [ 46.629856] ksyswrite+0xcd/0x13b [ 46.630128] dosyscall64+0xd4/0x139 [ 46.630420] entrySYSCALL64afterhwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasansavestack+0x24/0x44 [ 46.631493] kasansavetrack+0x14/0x2d [ 46.631799] kasansavefreeinfo+0x3f/0x4d [ 46.632144] _kasanslab_free+0x37/0x45 [ 46.632474] ---truncated---(CVE-2024-50150)

In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unusevma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pudclearbad is called by pudnoneorclearbad in unusepudrange() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unusevma to fix it.(CVE-2024-50199)

In the Linux kernel, the following vulnerability has been resolved: posix-clock: posix-clock: Fix unbalanced locking in pcclocksettime() If getclockdesc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64validstrict() before getclockdesc() to fix it, because the "ts" is not changed after that. pabeni@redhat.com: fixed commit message typo

In the Linux kernel, the following vulnerability has been resolved: USB: serial: ioedgeport: fix use after free in debug printk The "devdbg(&urb->dev->dev, ..." which happens after usbfreeurb(urb) is a use after free of the "urb" pointer. Store the "dev" pointer at the start of the function to avoid this issue.(CVE-2024-50267)

In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cachecreate to allocate new in-core data structures that fit the new size, and the check in cachepreresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in isdirtycallback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpgprecalculateline() blindly rescales the buffer even when scaledwitdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARNON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)

In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)

In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVCVSUNDEFINED in uvcparseformat This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvcparsestreaming.(CVE-2024-53104)