OESA-2024-2370

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvcfunctionsetup permits control transfer requests with up to 64 bytes of payload (UVCMAXREQUESTSIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvcevent->data.data array of size 60. This may result in an overflow of 4 bytes.(CVE-2022-48948)

In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.(CVE-2022-48949)

In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hix5hd2rx() The skb is delivered to napigro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48960)

In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hisifemacrx() The skb is delivered to napigroreceive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48962)

In the Linux kernel, the following vulnerability has been resolved: net: mvneta: Prevent out of bounds read in mvnetaconfigrss() The pp->indir[0] value comes from the user. It is passed to: if (cpuonline(pp->rxqdef)) inside the mvnetapercpuelect() function. It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap.(CVE-2022-48966)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix not cleanup led when btinit fails btinit() calls btledsinit() to register led, but if it fails later, btledscleanup() is not called to unregister it. This can cause panic if the argument "bluetooth-power" in text is freed and then another ledtriggerregister() tries to access it: BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Call Trace: <TASK> ledtriggerregister+0x10d/0x4f0 ledtriggerregistersimple+0x7d/0x100 btinit+0x39/0xf7 [bluetooth] dooneinitcall+0xd0/0x4e0(CVE-2022-48971)

In the Linux kernel, the following vulnerability has been resolved: mac802154: fix missing INITLISTHEAD in ieee802154ifadd() Kernel fault injection test reports null-ptr-deref as follows: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154netdevnotifiercall+0x120/0x310 include/linux/list.h:114 Call Trace: <TASK> rawnotifiercallchain+0x6d/0xa0 kernel/notifier.c:87 callnetdevicenotifiersinfo+0x6e/0xc0 net/core/dev.c:1944 unregisternetdevicemanynotify+0x60d/0xcb0 net/core/dev.c:1982 unregisternetdevicequeue+0x154/0x1a0 net/core/dev.c:10879 registernetdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154ifadd+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154registerhw+0x29c/0x330 net/mac802154/main.c:229 mcr20aprobe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316 ieee802154ifadd() allocates wpandev as netdev's private data, but not init the list in struct wpandev. cfg802154netdevnotifiercall() manage the list when device register/unregister, and may lead to null-ptr-deref. Use INITLIST_HEAD() on it to initialize it correctly.(CVE-2022-48972)

In the Linux kernel, the following vulnerability has been resolved: HID: core: fix shift-out-of-bounds in hidreportrawevent Syzbot reported shift-out-of-bounds in hidreportrawevent. microsoft 0003:045E:07DA.0001: hidfieldextract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e3/0x2cb lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:151 [inline] _ubsanhandleshiftoutofbounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hidinputfetchfield drivers/hid/hid-core.c:1572 [inline] hidprocessreport drivers/hid/hid-core.c:1665 [inline] hidreportrawevent+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hidinputreport+0x408/0x4f0 drivers/hid/hid-core.c:2066 hidirqin+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 _usbhcdgivebackurb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummytimer+0x86b/0x3110 drivers/usb/gadget/udc/dummyhcd.c:1988 calltimerfn+0xf5/0x210 kernel/time/timer.c:1474 expiretimers kernel/time/timer.c:1519 [inline] _runtimers+0x76a/0x980 kernel/time/timer.c:1790 runtimersoftirq+0x63/0xf0 kernel/time/timer.c:1803 _dosoftirq+0x277/0x75b kernel/softirq.c:571 _irqexitrcu+0xec/0x170 kernel/softirq.c:650 irqexitrcu+0x5/0x20 kernel/softirq.c:662 sysvecapictimerinterrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ====================================================================== If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32.(CVE-2022-48978)

In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-pcm: Add NULL check in BE reparenting Add NULL check in dpcmbereparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test.(CVE-2022-48992)

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmardevscopeinit() foreachpcidev() is implemented by pcigetdevice(). The comment of pcigetdevice() says that it will increase the reference count for the returned pcidev and also decrease the reference count for the input pcidev @from if it is not NULL. If we break foreachpcidev() loop with pdev not NULL, we need to call pcidevput() to decrease the reference count. Add the missing pcidev_put() for the error path to avoid reference count leak.(CVE-2022-49002)

In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Fix bounds check for sx controls For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in sndsocputvolsw_sx() needs to just check against the maximum value.(CVE-2022-49005)

In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) fix pci device refcount leak in nv1aramnew() As comment of pcigetdomainbusandslot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pcidev_put(). So call it after using to avoid refcount leak.(CVE-2022-49011)

In the Linux kernel, the following vulnerability has been resolved: net/9p: Fix a potential socket leak in p9socketopen Both p9fdcreatetcp() and p9fdcreateunix() will call p9socketopen(). If the creation of p9transfd fails, p9fdcreatetcp() and p9fdcreateunix() will return an error directly instead of releasing the cscoket, which will result in a socket leak. This patch adds sock_release() to fix the leak issue.(CVE-2022-49020)

In the Linux kernel, the following vulnerability has been resolved: net: phy: fix null-ptr-deref while probe() failed I got a null-ptr-deref report as following when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klistput+0x2d/0xd0 Call Trace: <TASK> klistremove+0xf1/0x1c0 devicereleasedriverinternal+0x23e/0x2d0 busremovedevice+0x1bd/0x240 devicedel+0x357/0x770 phydeviceremove+0x11/0x30 mdiobusunregister+0xa5/0x140 releasenodes+0x6a/0xa0 devresreleaseall+0xf8/0x150 deviceunbindcleanup+0x19/0xd0 //probe path: phydeviceregister() deviceadd() phyconnect phyattachdirect() //set device driver probe() //it's failed, driver is not bound devicebinddriver() // probe failed, it's not called //remove path: phydeviceremove() devicedel() devicereleasedriverinternal() _devicereleasedriver() //dev->drv is not NULL klistremove() <- knodedriver is not added yet, cause null-ptr-deref In phyattachdirect(), after setting the 'dev->driver', probe() fails, devicebinddriver() is not called, so the knodedriver->nklist is not set, then it causes null-ptr-deref in _devicereleasedriver() while deleting device. Fix this by setting dev->driver to NULL in the error path in phyattachdirect().(CVE-2022-49021)

In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4403: Fix oob read in afe4403readraw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4403readraw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279 Call Trace: afe4403readraw iioreadchannelinfo devattrshow The buggy address belongs to the variable: afe4403channelleds+0x18/0xffffffffffffe9e0 This issue can be reproduced by singe command: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/inintensity6raw The array size of afe4403channelleds is less than channels, so access with chan->address cause OOB read in afe4403read_raw. Fix it by moving access before use it.(CVE-2022-49031)

In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4404: Fix oob read in afe4404[read|write]raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404readraw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404readraw iioreadchannelinfo devattrshow The buggy address belongs to the variable: afe4404channelleds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/inintensity6raw The array size of afe4404channelleds and afe4404channeloffdacs are less than channels, so access with chan->address cause OOB read in afe4404[read|write]_raw. Fix it by moving access before use them.(CVE-2022-49032)

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

smack: tcp: ipv4, fix incorrect labeling

Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write.

Here is a scenario how to see this:

• Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels)

• At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment)

• At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections

• From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works.

• Send some data in both directions.

• Collect network traffic of this connection.

All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C.

If anybody cares: exactly the same happens with DCCP.

This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided.

I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.(CVE-2024-47659)

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

nilfs2: fix state management in error path of log writing function

After commit a694291a6211 ("nilfs2: separate wait function from nilfssegctorwrite") was applied, the log writing function nilfssegctordo_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling.

First, if nilfssegctorbeginconstruction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfssegctorabortconstruction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncateinodepagesfinal(), which is called via nilfsevict_inode() when an inode is evicted from memory, will hang.

Second, the NILFSICOLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFSICOLLECTED set are erroneously removed from the "scdirtyfiles" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping.

Fix these issues by uniformly calling nilfssegctorabortconstruction() on failure of each step in the loop in nilfssegctordoconstruct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfsredirtyinodes() to ensure that the NILFSICOLLECTED flag is cleared.(CVE-2024-47669)

In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:atkernel/workqueue.c:#checkflushdependency In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), the function flushworkqueue is invoked to flush the work queue iwcmwq. But at that time, the work queue iwcmwq was created via the function allocorderedworkqueue without the flag WQMEMRECLAIM. Because the current process is trying to flush the whole iwcmwq, if iwcmwq doesn't have the flag WQMEMRECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQMEMRECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] <TASK> [ 125.361285][ T1430] ? warn (kernel/panic.c:693) [ 125.367640][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? reportbug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handlebug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? excinvalidop (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asmexcinvalidop (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? checkflushdependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] _flushworkqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? _pfxmightresched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroycmid (drivers/infiniband/core/iwcm.c:375) iwcm [ 125.441209][ T1430] ? pfxflushworkqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _rawspinlockirqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlockapismp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? pfxrawspinlockirqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroyid (drivers/infiniband/core/cma.c:2044) rdmacm [ 125.495072][ T1430] nvmerdmafreequeue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvmerdma [ 125.505827][ T1430] nvmerdmaresetctrlwork (drivers/nvme/host/rdma.c:2180) nvmerdma [ 125.505831][ T1430] processonework (kernel/workqueue.c:3231) [ 125.515122][ T1430] workerthread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? _pfxworkerthread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? _pfxkthread (kernel/kthread.c:342) [ 125.550628][ T1430] retfromfork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? _pfxkthread (kernel/kthread.c:342) [ 125.558844][ T1430] retfromforkasm (arch/x86/entry/entry64.S:257) [ 125.566487][ T1430] </TASK> [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)

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: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if evalueoffs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4searchdir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 ext4searchdir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4findinlineentry+0x4be/0x5e0 fs/ext4/inline.c:1697 _ext4findentry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4lookupentry fs/ext4/namei.c:1727 [inline] ext4lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookuponeqstrexcl+0x11f/0x260 fs/namei.c:1633 filenamecreate+0x297/0x540 fs/namei.c:3980 dosymlinkat+0xf9/0x3a0 fs/namei.c:4587 _dosyssymlinkat fs/namei.c:4610 [inline] _sesyssymlinkat fs/namei.c:4607 [inline] _x64syssymlinkat+0x95/0xb0 fs/namei.c:4607 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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:00007fff4d40c258 EFLAGS: 00000246 ORIGRAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 </TASK> Calling ext4xattribodyfind right after reading the inode with ext4getinodeloc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)

In the Linux kernel, the following vulnerability has been resolved: firmwareloader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfcsli4requestfirmwareupdate() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfcfillvpd() - nfpnetfwfind() seems to construct a firmware filename from a model name coming from nfphwinfolookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic%s", and there shouldn't be any *folders* starting with "netronome/nic". The previous case was different because there, the "%s" is at the start of the format string.) - moduleflashfwschedule() is reachable from the ETHTOOLMSGMODULEFWFLASHACT netlink command, which is marked as GENLUNSADMINPERM (meaning CAPNETADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAPNET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)

In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of STR method Only buffer objects are valid return values of _STR. If something else is returned descriptionshow() will access invalid memory.(CVE-2024-49860)

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2setbufferuptodate When doing cleanup, if flags without OCFS2BHREADAHEAD, it may trigger NULL pointer dereference in the following ocfs2setbufferuptodate() if bh is NULL.(CVE-2024-49877)

In the Linux kernel, the following vulnerability has been resolved: resource: fix regionintersects() vs addmemorydrivermanaged() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls addmemorydrivermanaged() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses regionintersects(), which expects all "System RAM" resources to be at the top level of iomemresource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmemisallowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 _ioremapcaller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlatedevmemptr+0x25/0x2f writemem+0x94/0xfb vfswrite+0x128/0x26d ksyswrite+0xac/0xfe dosyscall64+0x9a/0xfd entrySYSCALL64afterhwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, regionintersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmemisallowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, regionintersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for regionintersects(, IORESOURCESYSTEMRAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".(CVE-2024-49878)

In the Linux kernel, the following vulnerability has been resolved: ext4: update origpath in ext4findextent() In ext4findextent(), if the path is not big enough, we free it and set *origpath to NULL. But after reallocating and successfully initializing the path, we don't update orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(ppath = NULL) path = *ppath; ex = path[depth].pext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4splitextentat+0x6d/0x560 Call Trace: <TASK> ext4splitextent.isra.0+0xcb/0x1b0 ext4extconverttoinitialized+0x168/0x6c0 ext4exthandleunwrittenextents+0x325/0x4d0 ext4extmapblocks+0x520/0xdb0 ext4mapblocks+0x2b0/0x690 ext4iomapbegin+0x20e/0x2c0 [...] ================================================================== Therefore, *origpath is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4exttrytomergeup(), set path[1].pbh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4extmapblocks ext4exthandleunwrittenextents ext4splitconvertextents // path->pdepth == 0 ext4splitextent // 1. do split1 ext4splitextentat |ext4extinsertextent | ext4extcreatenewleaf | ext4extgrowindepth | le16addcpu(&neh->ehdepth, 1) | ext4findextent | // return -ENOMEM |// get error and try zeroout |path = ext4findextent | path->pdepth = 1 |ext4exttrytomerge | ext4exttrytomergeup | path->pdepth = 0 | brelse(path[1].pbh) ---> not set to NULL here |// zeroout success // 2. update path ext4findextent // 3. do split2 ext4splitextentat ext4extinsertextent ext4extcreatenewleaf ext4extgrowindepth le16addcpu(&neh->ehdepth, 1) ext4findextent path[0].pbh = NULL; path->pdepth = 1 readextenttreeblock ---> return err // path[1].pbh is still the old value ext4freeextpath ext4extdroprefs // path->pdepth == 1 brelse(path[1].pbh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:brelse+0x58/0x90 Call Trace: <TASK> _findgetblock+0x6e7/0x810 bdevgetblk+0x2b/0x480 _ext4getinodeloc+0x48a/0x1240 ext4getinodeloc+0xb2/0x150 ext4reserveinodewrite+0xb7/0x230 _ext4markinodedirty+0x144/0x6a0 ext4extinsertextent+0x9c8/0x3230 ext4extmapblocks+0xf45/0x2dc0 ext4mapblocks+0x724/0x1700 ext4do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)

In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4extinsertextent() As Ojaswin mentioned in Link, in ext4extinsertextent(), if the path is reallocated in ext4extcreatenewleaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4extinsertextent path = *ppath = 2000 ext4extcreatenewleaf(ppath) ext4findextent(ppath) path = *ppath = 2000 if (depth > path[0].pmaxdepth) kfree(path = 2000); ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; / here path is still 2000, UAF! */ eh = path[depth].phdr ================================================================== BUG: KASAN: slab-use-after-free in ext4extinsertextent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: <TASK> ext4extinsertextent+0x26d4/0x3330 ext4extmapblocks+0xe22/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 [...] Allocated by task 179: ext4findextent+0x81c/0x1f70 ext4extmapblocks+0x146/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 ext4writepages+0x26d/0x4e0 dowritepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4findextent+0x7c0/0x1f70 ext4extinsertextent+0xa26/0x3330 ext4extmapblocks+0xe22/0x2d40 ext4mapblocks+0x71e/0x1700 ext4dowritepages+0x1290/0x2800 ext4writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)

In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4splitextentat() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4splitextentat+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: <TASK> kasanreport+0x93/0xc0 ext4splitextentat+0xba8/0xcc0 ext4splitextent.isra.0+0x18f/0x500 ext4splitconvertextents+0x275/0x750 ext4exthandleunwrittenextents+0x73e/0x1580 ext4extmapblocks+0xe20/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] Allocated by task 40: _kmallocnoprof+0x1ac/0x480 ext4findextent+0xf3b/0x1e70 ext4extmapblocks+0x188/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4findextent+0xa71/0x1e70 ext4extinsertextent+0xa22/0x3260 ext4splitextentat+0x3ef/0xcc0 ext4splitextent.isra.0+0x18f/0x500 ext4splitconvertextents+0x275/0x750 ext4exthandleunwrittenextents+0x73e/0x1580 ext4extmapblocks+0xe20/0x2dc0 ext4mapblocks+0x724/0x1700 ext4dowritepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4splitextentat path = *ppath ext4extinsertextent(ppath) ext4extcreatenewleaf(ppath) ext4findextent(origpath) path = *origpath readextenttreeblock // return -ENOMEM or -EIO ext4freeextpath(path) kfree(path) *origpath = NULL a. If err is -ENOMEM: ext4extdirty(path + path->pdepth) // path use-after-free !!! b. If err is -EIO and we have EXTDEBUG defined: ext4extshowleaf(path) eh = path[depth].phdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4findextent() to update the path. In addition we use *ppath directly as an ext4extshowleaf() input to avoid possible use-after-free when EXTDEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4extshowleaf() In ext4findextent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4splitextent path = *ppath; ext4splitextentat(ppath) path = ext4findextent(ppath) ext4splitextentat(ppath) // ext4findextent fails to free path // but zeroout succeeds ext4extshowleaf(inode, path) eh = path[depth].phdr // path use-after-free !!! Similar to ext4splitextentat(), we use *ppath directly as an input to ext4extshowleaf(). Fix a spelling error by the way. Same problem in ext4exthandleunwrittenextents(). Since 'path' is only used in ext4extshowleaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)

In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafbtask() In the pxafbprobe function, it calls the pxafbinitfbinfo function, after which &fbi->task is associated with pxafbtask. Moreover, within this pxafbinitfbinfo function, the pxafbblank function within the &pxafbops struct is capable of scheduling work. If we remove the module which will call pxafbremove to make cleanup, it will call unregisterframebuffer function which can call dounregisterframebuffer to free fbi->fb through putfbinfo(fbinfo), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafbtask pxafbremove | unregisterframebuffer(info) | dounregisterframebuffer(fbinfo) | putfbinfo(fbinfo) | // free fbi->fb | setctrlrstate(fbi, state) | _pxafblcdpower(fbi, 0) | fbi->lcdpower(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafbremove. Note that only root user can remove the driver at runtime.(CVE-2024-49924)

In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvifflushhash() During the listforeachentryrcu iteration call of xenvifflushhash, kfreercu does not exist inside the rcu read critical section, so if kfreercu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to listforeachentrysafe.(CVE-2024-49936)

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2capconnect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2capconnect.constprop.0+0x10d8/0x1270 net/bluetooth/l2capcore.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hcirxwork Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 l2capconnect.constprop.0+0x10d8/0x1270 net/bluetooth/l2capcore.c:3949 l2capconnectreq net/bluetooth/l2capcore.c:4080 [inline] l2capbredrsigcmd net/bluetooth/l2capcore.c:4772 [inline] l2capsigchannel net/bluetooth/l2capcore.c:5543 [inline] l2caprecvframe+0xf0b/0x8eb0 net/bluetooth/l2capcore.c:6825 l2caprecvacldata+0x9b4/0xb70 net/bluetooth/l2capcore.c:7514 hciacldatapacket net/bluetooth/hcicore.c:3791 [inline] hcirxwork+0xaab/0x1610 net/bluetooth/hcicore.c:4028 processonework+0x9c5/0x1b40 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 ... Freed by task 5245: kasansavestack+0x33/0x60 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:579 poisonslabobject+0xf7/0x160 mm/kasan/common.c:240 _kasanslabfree+0x32/0x50 mm/kasan/common.c:256 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2256 [inline] slabfree mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2capconnfree net/bluetooth/l2capcore.c:1810 [inline] krefput include/linux/kref.h:65 [inline] l2capconnput net/bluetooth/l2capcore.c:1822 [inline] l2capconndel+0x59d/0x730 net/bluetooth/l2capcore.c:1802 l2capconnectcfm+0x9e6/0xf80 net/bluetooth/l2capcore.c:7241 hciconnectcfm include/net/bluetooth/hcicore.h:1960 [inline] hciconnfailed+0x1c3/0x370 net/bluetooth/hciconn.c:1265 hciabortconnsync+0x75a/0xb50 net/bluetooth/hcisync.c:5583 abortconnsync+0x197/0x360 net/bluetooth/hciconn.c:2917 hcicmdsyncwork+0x1a4/0x410 net/bluetooth/hcisync.c:328 processonework+0x9c5/0x1b40 kernel/workqueue.c:3231 processscheduledworks kernel/workqueue.c:3312 [inline] workerthread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244(CVE-2024-49950)

In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venusremove due to race condition in venusprobe, core->work is bound with venussyserrorhandler, which is used to handle error. The code use core->syserrdone to make sync work. The core->work is started in venuseventnotify. If we call venusremove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venussyserrorhandler venusremove | hfidestroy | venushfidestroy | kfree(hdev); | |hfireinit |venushfiqueuesreinit |//use hdev Fix it by canceling the work in venusremove.(CVE-2024-49981)

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: tipc: guard against string buffer overrun Smatch reports that copying medianame and ifname to nameparts may overwrite the destination. .../bearer.c:166 bearernamevalidate() error: strcpy() 'medianame' too large for 'nameparts->medianame' (32 vs 16) .../bearer.c:167 bearernamevalidate() error: strcpy() 'ifname' too large for 'nameparts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a ("[TIPC] Initial merge") Compile tested only.(CVE-2024-49995)

In the Linux kernel, the following vulnerability has been resolved: slip: make slhcremember() more robust against malicious packets syzbot found that slhcremember() was missing checks against malicious packets [1]. slhcremember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhcremember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhcremember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 pppreceivenonmpframe+0xe45/0x35e0 drivers/net/ppp/pppgeneric.c:2455 pppreceiveframe drivers/net/ppp/pppgeneric.c:2372 [inline] pppdorecv+0x65f/0x40d0 drivers/net/ppp/pppgeneric.c:2212 pppinput+0x7dc/0xe60 drivers/net/ppp/pppgeneric.c:2327 pppoercvcore+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x13b/0x420 include/net/sock.h:1113 releasesock+0x1da/0x330 net/core/sock.c:3072 releasesock+0x6b/0x250 net/core/sock.c:3626 pppoesendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 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:4091 [inline] slaballocnode mm/slub.c:4134 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4186 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:587 _allocskb+0x363/0x7b0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1322 [inline] sockwmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoesendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 _syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 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: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)

In the Linux kernel, the following vulnerability has been resolved: ppp: fix pppasyncencode() illegal access syzbot reported an issue in pppasyncencode() [1] In this case, pppoesendmsg() is called with a zero size. Then pppasyncencode() is called with an empty skb. BUG: KMSAN: uninit-value in pppasyncencode drivers/net/ppp/pppasync.c:545 [inline] BUG: KMSAN: uninit-value in pppasyncpush+0xb4f/0x2660 drivers/net/ppp/pppasync.c:675 pppasyncencode drivers/net/ppp/pppasync.c:545 [inline] pppasyncpush+0xb4f/0x2660 drivers/net/ppp/pppasync.c:675 pppasyncsend+0x130/0x1b0 drivers/net/ppp/pppasync.c:634 pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2280 [inline] pppinput+0x1f1/0xe60 drivers/net/ppp/pppgeneric.c:2304 pppoercvcore+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x13b/0x420 include/net/sock.h:1113 releasesock+0x1da/0x330 net/core/sock.c:3072 releasesock+0x6b/0x250 net/core/sock.c:3626 pppoesendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 _syssendmsg+0x903/0xb60 net/socket.c:2602 syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 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:4092 [inline] slaballocnode mm/slub.c:4135 [inline] kmemcacheallocnodenoprof+0x6bf/0xb80 mm/slub.c:4187 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:587 _allocskb+0x363/0x7b0 net/core/skbuff.c:678 allocskb include/linux/skbuff.h:1322 [inline] sockwmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoesendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 socksendmsgnosec net/socket.c:729 [inline] _socksendmsg+0x30f/0x380 net/socket.c:744 syssendmsg+0x903/0xb60 net/socket.c:2602 _syssendmsg+0x28d/0x3c0 net/socket.c:2656 _syssendmmsg+0x3c1/0x960 net/socket.c:2742 _dosyssendmmsg net/socket.c:2771 [inline] _sesyssendmmsg net/socket.c:2768 [inline] _x64syssendmmsg+0xbc/0x120 net/socket.c:2768 x64syscall+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:308 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)

In the Linux kernel, the following vulnerability has been resolved: serial: protect uartportdtrrts() in uartshutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uartshutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uartportdtrrts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)

In the Linux kernel, the following vulnerability has been resolved: tty: ngsm: Fix use-after-free in gsmcleanupmux BUG: KASAN: slab-use-after-free in gsmcleanupmux+0x77b/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsmcleanupmux+0x77b/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] _pfxgsmcleanupmux+0x10/0x10 drivers/tty/ngsm.c:3124 [ngsm] _pfxschedclockcpu+0x10/0x10 kernel/sched/clock.c:389 updateloadavg+0x1c1/0x27b0 kernel/sched/fair.c:4500 _pfxminvruntimecbrotate+0x10/0x10 kernel/sched/fair.c:846 _rbinsertaugmented+0x492/0xbf0 lib/rbtree.c:161 gsmldioctl+0x395/0x1450 drivers/tty/ngsm.c:3408 [ngsm] rawspinlockirqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 _pfxgsmldioctl+0x10/0x10 drivers/tty/ngsm.c:3822 [ngsm] ktimeget+0x5e/0x140 kernel/time/timekeeping.c:195 ldsemdownread+0x94/0x4e0 arch/x86/include/asm/atomic6464.h:79 _pfxldsemdownread+0x10/0x10 drivers/tty/ttyldsem.c:338 _pfxdovfsioctl+0x10/0x10 fs/ioctl.c:805 ttyioctl+0x643/0x1100 drivers/tty/ttyio.c:2818 Allocated by task 65: gsmdataalloc.constprop.0+0x27/0x190 drivers/tty/ngsm.c:926 [ngsm] gsmsend+0x2c/0x580 drivers/tty/ngsm.c:819 [ngsm] gsm1receive+0x547/0xad0 drivers/tty/ngsm.c:3038 [ngsm] gsmldreceivebuf+0x176/0x280 drivers/tty/ngsm.c:3609 [ngsm] ttyldiscreceivebuf+0x101/0x1e0 drivers/tty/ttybuffer.c:391 ttyportdefaultreceivebuf+0x61/0xa0 drivers/tty/ttyport.c:39 flushtoldisc+0x1b0/0x750 drivers/tty/ttybuffer.c:445 processscheduledworks+0x2b0/0x10d0 kernel/workqueue.c:3229 workerthread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 retfromfork+0x2d/0x70 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsmcleanupmux+0x36c/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] gsmldioctl+0x395/0x1450 drivers/tty/ngsm.c:3408 [ngsm] ttyioctl+0x643/0x1100 drivers/tty/ttyio.c:2818 [Analysis] gsmmsg on the txctrllist or txdatalist of gsmmux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)