OESA-2024-2537

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhciinvalidatecancelledtds() again from xhcihandlecmdsetdeq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhciwarn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhcidbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhcidbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn't really hint at there being a problem at all). It took me months of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn't have been left in at all). > Another fix to solve clearing the caches of all stream rings with > cancelled TDs is needed, but not as urgent. 3 years after that statement and 14 years after the original bug was introduced, I think it's finally time to fix it. And maybe next time let's not leave bugs unfixed (that are actually worse than the original bug), and let's actually get people to review kernel commits please. Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use hdparm to mark an early sector (e.g. 1024) on a disk as bad, then cat /dev/sdX > /dev/null in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn't get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the cat in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro'd and tested on an Apple M1 Mac Mini (dwc3 host). On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---(CVE-2024-40927)

In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830pidfilter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so setbit and clearbit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.(CVE-2024-47697)

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211dostop() Since '_devqueuexmit()' should be called with interrupts enabled, the following backtrace: ieee80211dostop() ... spinlockirqsave(&local->queuestopreasonlock, flags) ... ieee80211freetxskb() ieee80211reportusedskb() ieee80211reportackskb() cfg80211mgmttxstatusext() nl80211frametxstatus() genlmsgmulticastnetns() genlmsgmulticastnetnsfiltered() nlmsgmulticastfiltered() netlinkbroadcastfiltered() doonebroadcast() netlinkbroadcastdeliver() _netlinksendskb() netlinkdelivertap() _netlinkdelivertapskb() devqueuexmit() _devqueuexmit() ; with IRQS disabled ... spinunlockirqrestore(&local->queuestopreasonlock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 _localbhenableip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211dostop()', where actual work is performed outside of a section with interrupts disabled.(CVE-2024-47713)

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024(CVE-2024-47738)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantomstream before it is used dcn32enablephantomstream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.(CVE-2024-49897)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20validateapplypipesplitflags [WHAT & HOW] "dcn20validateapplypipesplitflags" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49923)

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") allows the "porttransmitratekbps" to be set to a value of 0, which is then passed to the "divs64" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.(CVE-2024-49977)

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfdfreegttmem clear the correct pointer Pass pointer reference to amdgpubounref to clear the correct pointer, otherwise amdgpubo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.(CVE-2024-49991)

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiqetop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skbput_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.(CVE-2024-49997)

In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asocqcomlpasscpuplatformprobe() A devmkzalloc() in asocqcomlpasscpuplatform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.(CVE-2024-50103)

In the Linux kernel, the following vulnerability has been resolved: x86/lam: Disable ADDRESSMASKING in most cases Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable. Until kernel adds support for LASS[2], only allow LAM for COMPILETEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled. There are no processors in market that support LAM yet, so currently nobody is affected by this issue. [1] SLAM: https://download.vusec.net/papers/slamsp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ dhansen: update SPECULATIONMITIGATIONS -> CPU_MITIGATIONS

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUGON check for the buffer delay flag in submitbh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.(CVE-2024-50116)

In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)(CVE-2024-50117)

In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbvamousepointershape with real VLA Replace the fake VLA at end of the vbvamousepointershape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmibase.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmibase.c:154 hgsmiupdatepointershape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmiupdatepointershape [vboxvideo] [ 13.320184] vboxcursoratomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.(CVE-2024-50134)

In the Linux kernel, the following vulnerability has been resolved: firmware: armscmi: Fix the double free in scmidebugfscommonsetup() Clang static checker(scan-build) throws below warning： | drivers/firmware/armscmi/driver.c:line 2915, column 2 | Attempt to free released memory. When devmaddactionorreset() fails, scmidebugfscommoncleanup() will run twice which causes double free of 'dbg->name'. Remove the redundant scmidebugfscommon_cleanup() to fix this problem.(CVE-2024-50159)

(CVE-2024-50194)

In the Linux kernel, the following vulnerability has been resolved: mapletree: correct tree corruption on spanning store Patch series "mapletree: correct tree corruption on spanning store", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 ("mm/mmap: avoid zeroing vma tree in mmapregion()"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in maswrspanningstore() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by maswrspanningstore(). In order to reach this stage, masstoregfp() invokes maswrpreallocate(), maswrstoretype() and maswrwalk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and maswrstoretype() marks the mas->storetype as wrspanningstore to denote this fact. When we go to perform the store in maswrspanningstore(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. rmas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by lmas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by masstorebnode(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. rmas.offset <= rmas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \ pivot = 0xffff / \ pivot = ULONG_MAX / ---truncated---(CVE-2024-50200)

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: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spigetcsgpiod() to avoid passing a NULL pointer to gpioddirectionoutput(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but activemm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpioddirectionoutput+0x34/0x5c [ 4.344505] lr : gpioddirectionoutput+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpioddirectionoutput+0x34/0x5c (P) [ 4.431067] gpioddirectionoutput+0x18/0x5c (L) [ 4.435771] dspisetup+0x220/0x334(CVE-2024-50224)

In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.(CVE-2024-50239)

In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmwlock a rawspinlock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpcptr->rmwlock){+.+.}-{3:3}, at: cpcwrite+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->_lock){-.-.}-{2:2}, at: rawspinrqlocknested+0x2c/0x50 #1: ffffff880154e238 (&sgpolicy->updatelock){....}-{2:2}, at: sugovupdateshared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dumpbacktrace+0xa4/0x130 showstack+0x20/0x38 dumpstacklvl+0x90/0xd0 dumpstack+0x18/0x28 _lockacquire+0x480/0x1ad8 lockacquire+0x114/0x310 _rawspinlock+0x50/0x70 cpcwrite+0xcc/0x370 cppcsetperf+0xa0/0x3a8 cppccpufreqfastswitch+0x40/0xc0 cpufreqdriverfastswitch+0x4c/0x218 sugovupdateshared+0x234/0x280 updateloadavg+0x6ec/0x7b8 dequeueentities+0x108/0x830 dequeuetaskfair+0x58/0x408 _schedule+0x4f0/0x1070 schedule+0x54/0x130 workerthread+0xc0/0x2e8 kthread+0x130/0x148 retfromfork+0x10/0x20 sugovupdateshared() locks a rawspinlock while cpcwrite() locks a spinlock. To have a correct wait-type order, update rmwlock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. rjw: Changelog edits

In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in getinfo() ip6tablenat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 moduleput+0x6f/0x80 Modules linked in: ip6tablenat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:moduleput+0x6f/0x80 Call Trace: <TASK> getinfo+0x128/0x180 doip6tgetctl+0x6a/0x430 nfgetsockopt+0x46/0x80 ipv6getsockopt+0xb9/0x100 rawv6getsockopt+0x42/0x190 dosockgetsockopt+0xaa/0x180 _sysgetsockopt+0x70/0xc0 _x64sysgetsockopt+0x20/0x30 dosyscall64+0xa2/0x1a0 entrySYSCALL64afterhwframe+0x77/0x7f Concurrent execution of module unload and getinfo() trigered the warning. The root cause is as follows: cpu0 cpu1 moduleexit //mod->state = MODULESTATEGOING ip6tablenatexit xtunregistertemplate kfree(t) //removed from templlist getinfo() t = xtfindtablelock listforeachentry(tmpl, &xttemplates[af]...) if (strcmp(tmpl->name, name)) continue; //table not found trymoduleget listforeachentry(t, &xtnet->tables[af]...) return t; //not get refcnt moduleput(t->me) //uaf unregisterpernetsubsys //remove table from xtnet list While xttable module was going away and has been removed from xttemplates list, we couldnt get refcnt of xttable->me. Check module in xt_net->tables list re-traversal to fix it.(CVE-2024-50257)

In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 ("fork: use _mtdup() to duplicate maple tree in dupmmap()") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dupmmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 ("mm: khugepaged: make khugepagedenter() void function") and make ksmfork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.(CVE-2024-50263)

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: usb: typec: fix potential out of bounds in ucsiccgupdatesetnewcamcmd() The "*cmd" variable can be controlled by the user via debugfs. That means "newcam" can be as high as 255 while the size of the uc->updated[] array is UCSIMAXALTMODES (30). The call tree is: ucsicmd() // val comes from simpleattrwritexsigned() -> ucsisendcommand() -> ucsisendcommandcommon() -> ucsiruncommand() // calls ucsi->ops->synccontrol() -> ucsiccgsynccontrol()(CVE-2024-50268)

In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 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 dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cachepreresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cachectr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.(CVE-2024-50279)

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: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.(CVE-2024-50290)

In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32spdifrxremove In case of error when requesting ctrlchan DMA channel, ctrlchan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dmarequestslavechannel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dmareleasechannel+0x24/0x100 [ 5.103235] stm32spdifrxremove+0x24/0x60 [sndsocstm32spdifrx] [ 5.109494] stm32spdifrxprobe+0x320/0x4c4 [sndsocstm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.(CVE-2024-50292)

In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in keytaskpermission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in _kuidval include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uideq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in keytaskpermission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: _dumpstack lib/dumpstack.c:82 [inline] dumpstack+0x107/0x167 lib/dumpstack.c:123 printaddressdescription.constprop.0+0x19/0x170 mm/kasan/report.c:400 _kasanreport.cold+0x6c/0x84 mm/kasan/report.c:560 kasanreport+0x3a/0x50 mm/kasan/report.c:585 _kuidval include/linux/uidgid.h:36 [inline] uideq include/linux/uidgid.h:63 [inline] keytaskpermission+0x394/0x410 security/keys/permission.c:54 searchnestedkeyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the searchnestedkeyrings function, when it iterates through the slots in a node(below tag ascendtonode), if the slot pointer is meta and node->backpointer != NULL(it means a root), it will proceed to descendtonode. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyringptriskeyring function. However, KEYRINGPTRSUBTYPE is 0x2UL, the same as ASSOCARRAYPTRSUBTYPEMASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descendtonode if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ jarkko: tweaked the commit message a bit to have an appropriate closes tag.

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: net/sched: stop qdisctreereducebacklog on TCHROOT In qdisctreereducebacklog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TCHROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisclookup with TCHMAJ(TCHROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TCHROOT, which then the iteration must stop. net/sched/schapi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)

In the Linux kernel, the following vulnerability has been resolved: firmware: armscmi: Fix slab-use-after-free in scmibusnotifier() The scmidev->name is released prematurely in _scmidevicedestroy(), which causes slab-use-after-free when accessing scmidev->name in scmibusnotifier(). So move the release of scmidev->name to scmidevicerelease() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dumpbacktrace+0x94/0x114 | showstack+0x18/0x24 | dumpstacklvl+0x48/0x60 | printreport+0xf4/0x5b0 | kasanreport+0xa4/0xec | _asanreportload1noabort+0x20/0x2c | strncmp+0xe4/0xec | scmibusnotifier+0x5c/0x54c | notifiercallchain+0xb4/0x31c | blockingnotifiercallchain+0x68/0x9c | busnotify+0x54/0x78 | devicedel+0x1bc/0x840 | deviceunregister+0x20/0xb4 | _scmidevicedestroy+0xac/0x280 | scmidevicedestroy+0x94/0xd0 | scmichansetup+0x524/0x750 | scmiprobe+0x7fc/0x1508 | platformprobe+0xc4/0x19c | reallyprobe+0x32c/0x99c | _driverprobedevice+0x15c/0x3c4 | driverprobedevice+0x5c/0x170 | _driverattach+0x1c8/0x440 | busforeachdev+0xf4/0x178 | driverattach+0x3c/0x58 | busadddriver+0x234/0x4d4 | driverregister+0xf4/0x3c0 | _platformdriverregister+0x60/0x88 | scmidriverinit+0xb0/0x104 | dooneinitcall+0xb4/0x664 | kernelinitfreeable+0x3c8/0x894 | kernelinit+0x24/0x1e8 | retfromfork+0x10/0x20 | | Allocated by task 1: | kasansavestack+0x2c/0x54 | kasansettrack+0x2c/0x40 | kasansaveallocinfo+0x24/0x34 | _kasankmalloc+0xa0/0xb8 | _kmallocnodetrackcaller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdupconst+0x34/0x40 | _scmidevicecreate.part.0+0x8c/0x408 | scmidevicecreate+0x104/0x370 | scmichansetup+0x2a0/0x750 | scmiprobe+0x7fc/0x1508 | platformprobe+0xc4/0x19c | reallyprobe+0x32c/0x99c | _driverprobedevice+0x15c/0x3c4 | driverprobedevice+0x5c/0x170 | _driverattach+0x1c8/0x440 | busforeachdev+0xf4/0x178 | driverattach+0x3c/0x58 | busadddriver+0x234/0x4d4 | driverregister+0xf4/0x3c0 | _platformdriverregister+0x60/0x88 | scmidriverinit+0xb0/0x104 | dooneinitcall+0xb4/0x664 | kernelinitfreeable+0x3c8/0x894 | kernelinit+0x24/0x1e8 | retfromfork+0x10/0x20 | | Freed by task 1: | kasansavestack+0x2c/0x54 | kasansettrack+0x2c/0x40 | kasansavefreeinfo+0x38/0x5c | _kasanslabfree+0xe8/0x164 | _kmemcachefree+0x11c/0x230 | kfree+0x70/0x130 | kfreeconst+0x20/0x40 | _scmidevicedestroy+0x70/0x280 | scmidevicedestroy+0x94/0xd0 | scmichansetup+0x524/0x750 | scmiprobe+0x7fc/0x1508 | platformprobe+0xc4/0x19c | reallyprobe+0x32c/0x99c | _driverprobedevice+0x15c/0x3c4 | driverprobedevice+0x5c/0x170 | _driverattach+0x1c8/0x440 | busforeachdev+0xf4/0x178 | driverattach+0x3c/0x58 | busadddriver+0x234/0x4d4 | driverregister+0xf4/0x3c0 | _platformdriverregister+0x60/0x88 | scmidriverinit+0xb0/0x104 | dooneinitcall+0xb4/0x664 | kernelinitfreeable+0x3c8/0x894 | kernelinit+0x24/0x1e8 | retfrom_fork+0x10/0x20(CVE-2024-53068)

In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amdpmc module as: amdpmc enablestb=1 ...can result in the following messages in the kernel ring buffer: amdpmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 _ioremapcaller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2DPHYSADDRLOW and S2DPHYSADDRHIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.(CVE-2024-53072)

In the Linux kernel, the following vulnerability has been resolved: virtionet: Add hashkeylength check Add hashkeylength check in virtnetprobe() to avoid possible out of bound errors when setting/reading the hash key.(CVE-2024-53082)

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)

In the Linux kernel, the following vulnerability has been resolved: vpvdpa: fix idtable array not null terminated error Allocate one extra virtiodeviceid as null terminator, otherwise vdpamgmtdevget_classes() may iterate multiple times and visit undefined memory.(CVE-2024-53110)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: <TASK> ? _diebody+0x5f/0xb0 ? die+0x9e/0xc0 ? dotrap+0x15a/0x3a0 ? ocfs2setnewbufferuptodate+0x145/0x160 ? doerrortrap+0x1dc/0x2c0 ? ocfs2setnewbufferuptodate+0x145/0x160 ? _pfxdoerrortrap+0x10/0x10 ? handleinvalidop+0x34/0x40 ? ocfs2setnewbufferuptodate+0x145/0x160 ? excinvalidop+0x38/0x50 ? asmexcinvalidop+0x1a/0x20 ? ocfs2setnewbufferuptodate+0x2e/0x160 ? ocfs2setnewbufferuptodate+0x144/0x160 ? ocfs2setnewbufferuptodate+0x145/0x160 ocfs2groupadd+0x39f/0x15a0 ? _pfxocfs2groupadd+0x10/0x10 ? _pfxlockacquire+0x10/0x10 ? mntgetwriteaccess+0x68/0x2b0 ? _pfxlockrelease+0x10/0x10 ? rcureadlockanyheld+0xb7/0x160 ? _pfxrcureadlockanyheld+0x10/0x10 ? smacklog+0x123/0x540 ? mntgetwriteaccess+0x68/0x2b0 ? mntgetwriteaccess+0x68/0x2b0 ? mntgetwriteaccess+0x226/0x2b0 ocfs2ioctl+0x65e/0x7d0 ? _pfxocfs2ioctl+0x10/0x10 ? smackfileioctl+0x29e/0x3a0 ? _pfxsmackfileioctl+0x10/0x10 ? lockdephardirqsonprepare+0x43d/0x780 ? _pfxlockdephardirqsonprepare+0x10/0x10 ? _pfxocfs2ioctl+0x10/0x10 _sesysioctl+0xfb/0x170 dosyscall64+0xf3/0x230 entrySYSCALL64afterhwframe+0x77/0x7f ... </TASK> When 'ioctl(OCFS2IOCGROUPADD, ...)' has failed for the particular inode in 'ocfs2verifygroupandinput()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2setnewbufferuptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2removefromcache()' on error path in 'ocfs2group_add()'.(CVE-2024-53112)

In the Linux kernel, the following vulnerability has been resolved: bpf: synclinkedregs() must preserve subregdef Range propagation must not affect subregdef marks, otherwise the following example is rewritten by verifier incorrectly when BPFFTESTRNDHI32 flag is set: 0: call bpfktimegetns call bpfktimegetns 1: r0 &= 0x7fffffff after verifier r0 &= 0x7fffffff 2: w1 = w0 rewrites w1 = w0 3: if w0 < 10 goto +0 --------------> r11 = 0x2f5674a6 (r) 4: r1 >>= 32 r11 <<= 32 (r) 5: r0 = r1 r1 |= r11 (r) 6: exit; if w0 < 0xa goto pc+0 r1 >>= 32 r0 = r1 exit (or zero extension of w1 at (2) is missing for architectures that require zero extension for upper register half). The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subregdef is overridden at (3) by copyregisterstate(); - w1 is read at (5) but markinsnzext() does not mark (2) for zero extension, because w1 subregdef is not set; - because of BPFFTESTRNDHI32 flag verifier inserts random value for hi32 bits of (2) (marked (r)); - this random value is read at (5).(CVE-2024-53125)

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in blockdirtybuffer tracepoint When using the "block:blockdirtybuffer" tracepoint, markbufferdirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in markbufferdirty(), it references the devt member bh->bbdev->bddev regardless of whether the buffer head has a pointer to a blockdevice structure. In the current implementation, nilfsgrabbuffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by trytofreebuffers(), and new buffer heads are then attached by createemptybuffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->bbdev, and markbufferdirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfsgrabbuffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.(CVE-2024-53130)