OESA-2024-1393

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

media: dvbdev: Fix memory leak in dvbmediadevice_free()

dvbmediadevicefree() is leaking memory. Free dvbdev->adapter->conn before setting it to NULL, as documented in include/media/media-device.h: "The mediaentity instance itself must be freed explicitly by the driver if required."(CVE-2020-36777)

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

i2c: sprd: fix reference leak when pmruntimeget_sync fails

The PM reference count is not expected to be incremented on return in sprdi2cmasterxfer() and sprdi2c_remove().

However, pmruntimeget_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.

Replace it with pmruntimeresumeandget to keep usage counter balanced.(CVE-2020-36780)

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

i2c: cadence: fix reference leak when pmruntimeget_sync fails

The PM reference count is not expected to be incremented on return in functions cdnsi2cmasterxfer and cdnsreg_slave.

However, pmruntimeget_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here.

Replace it with pmruntimeresumeandget to keep usage counter balanced.(CVE-2020-36784)

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

net: hso: fix null-ptr-deref during tty device unregistration

Multiple ttys try to claim the same the minor number causing a double unregistration of the same device. The first unregistration succeeds but the next one results in a null-ptr-deref.

The getfreeserialindex() function returns an available minor number but doesn't assign it immediately. The assignment is done by the caller later. But before this assignment, calls to getfreeserialindex() would return the same minor number.

Fix this by modifying getfreeserialindex to assign the minor number immediately after one is found to be and rename it to obtainminor() to better reflect what it does. Similary, rename setserialbyindex() to releaseminor() and modify it to free up the minor number of the given hsoserial. Every obtainminor() should have corresponding release_minor() call.(CVE-2021-46904)

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

NFC: st21nfca: Fix memory leak in device probe and remove

'phy->pending_skb' is alloced when device probe, but forgot to free in the error handling path and remove path, this cause memory leak as follows:

unreferenced object 0xffff88800bc06800 (size 512): comm "8", pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d66c09ce>] _kmallocnodetrackcaller+0x1ed/0x450 [<00000000c93382b3>] kmallocreserve+0x37/0xd0 [<000000005fea522c>] _allocskb+0x124/0x380 [<0000000019f29f9a>] st21nfcahcii2cprobe+0x170/0x8f2

Fix it by freeing 'pending_skb' in error and remove.(CVE-2021-46924)

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

ALSA: hda: intel-sdw-acpi: harden detection of controller

The existing code currently sets a pointer to an ACPI handle before checking that it's actually a SoundWire controller. This can lead to issues where the graph walk continues and eventually fails, but the pointer was set already.

This patch changes the logic so that the information provided to the caller is set when a controller is found.(CVE-2021-46926)

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

parisc: Clear stale IIR value on instruction access rights trap

When a trap 7 (Instruction access rights) occurs, this means the CPU couldn't execute an instruction due to missing execute permissions on the memory region. In this case it seems the CPU didn't even fetched the instruction from memory and thus did not store it in the cr19 (IIR) register before calling the trap handler. So, the trap handler will find some random old stale value in cr19.

This patch simply overwrites the stale IIR value with a constant magic "bad food" value (0xbaadf00d), in the hope people don't start to try to understand the various random IIR values in trap 7 dumps.(CVE-2021-46928)

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

i2c: validate user data in compat ioctl

Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. Userspace should not be able to trigger warnings, so this patch adds validation checks for user data in compact ioctl to prevent reported warnings(CVE-2021-46934)

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

binder: fix asyncfreespace accounting for empty parcels

In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area shared with user space") fixed a kernel structure visibility issue. As part of that patch, sizeof(void *) was used as the buffer size for 0-length data payloads so the driver could detect abusive clients sending 0-length asynchronous transactions to a server by enforcing limits on asyncfreesize.

Unfortunately, on the "free" side, the accounting of asyncfreespace did not add the sizeof(void *) back. The result was that up to 8-bytes of asyncfreespace were leaked on every async transaction of 8-bytes or less. These small transactions are uncommon, so this accounting issue has gone undetected for several years.

The fix is to use "buffersize" (the allocated buffer size) instead of "size" (the logical buffer size) when updating the asyncfree_space during the free operation. These are the same except for this corner case of asynchronous transactions with payloads < 8 bytes.(CVE-2021-46935)

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

NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds

Fix shift out-of-bounds in xprtcalcmajortimeo(). This is caused by a garbage timeout (retrans) mount option being passed to nfs mount, in this case from syzkaller.

If the protocol is XPRTTRANSPORTUDP, then 'retrans' is a shift value for a 64-bit long integer, so 'retrans' cannot be >= 64. If it is >= 64, fail the mount and return an error.(CVE-2021-46952)

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

hfsplus: prevent corruption in shrinking truncate

I believe there are some issues introduced by commit 31651c607151 ("hfsplus: avoid deadlock on file truncation")

HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file.

In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplusfiletruncate() was changed so that call to hfsbrecremove() is not guarded any more.

Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplusfreeextents(), and then check if the whole extent record should be removed. However since the guard (blkcnt > start) is now after the call to hfsbrec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally.

To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data.

Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfsbrecremove() can't be moved to it's previous place since we're dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data.

Another issue is related to this one. When entering into the block (blkcnt > start) we are not holding the ->treelock. We break out from the loop not holding the lock, but hfsfindexit() does unlock it. Not sure if it's possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there's no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check.(CVE-2021-46989)

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

x86/kvm: Teardown PV features on boot CPU as well

Various PV features (Async PF, PV EOI, steal time) work through memory shared with hypervisor and when we restore from hibernation we must properly teardown all these features to make sure hypervisor doesn't write to stale locations after we jump to the previously hibernated kernel (which can try to place anything there). For secondary CPUs the job is already done by kvmcpudown_prepare(), register syscore ops to do the same for boot CPU.(CVE-2021-47112)

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

btrfs: abort in rename_exchange if we fail to insert the second ref

Error injection stress uncovered a problem where we'd leave a dangling inode ref if we failed during a rename_exchange. This happens because we insert the inode ref for one side of the rename, and then for the other side. If this second inode ref insert fails we'll leave the first one dangling and leave a corrupt file system behind. Fix this by aborting if we did the insert for the first inode ref.(CVE-2021-47113)

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

ocfs2: fix data corruption by fallocate

When fallocate punches holes out of inode size, if original isize is in the middle of last cluster, then the part from isize to the end of the cluster will be zeroed with buffer write, at that time isize is not yet updated to match the new size, if writeback is kicked in, it will invoke ocfs2writepage()->blockwritefullpage() where the pages out of inode size will be dropped. That will cause file corruption. Fix this by zero out eof blocks when extending the inode size.

Running the following command with qemu-image 4.2.1 can get a corrupted coverted image file easily.

qemu-img convert -p -t none -T none -f qcow2 $qcow_image \
         -O qcow2 -o compat=1.1 $qcow_image.conv

The usage of fallocate in qemu is like this, it first punches holes out of inode size, then extend the inode size.

fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0
fallocate(11, 0, 2276196352, 65536) = 0

v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/(CVE-2021-47114)

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

net: caif: fix memory leak in caifdevicenotify

In case of caifenrolldev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error(CVE-2021-47122)

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

apparmor: avoid crash when parsed profile name is empty

When processing a packed profile in unpack_profile() described like

"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}"

a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then passed to aasplitnfqname().

aasplitnfqname() treats ":samba-dcerpcd" as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later aaallocprofile() crashes as the new profile name is NULL now.

general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmorparser Not tainted 6.7.0-rc2-dirty #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ? strlen+0x1e/0xa0 aapolicyinit+0x1bb/0x230 aaallocprofile+0xb1/0x480 unpackprofile+0x3bc/0x4960 aaunpack+0x309/0x15e0 aareplaceprofiles+0x213/0x33c0 policyupdate+0x261/0x370 profilereplace+0x20e/0x2a0 vfswrite+0x2af/0xe00 ksyswrite+0x126/0x250 dosyscall64+0x46/0xf0 entrySYSCALL64after_hwframe+0x6e/0x76 </TASK> ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0

It seems such behaviour of aasplitnfqname() is expected and checked in other places where it is called (e.g. aaremoveprofiles). Well, there is an explicit comment "a ns name without a following profile is allowed" inside.

AFAICS, nothing can prevent unpacked "name" to be in form like ":samba-dcerpcd" - it is passed from userspace.

Deny the whole profile set replacement in such case and inform user with EPROTO and an explaining message.

Found by Linux Verification Center (linuxtesting.org).(CVE-2023-52443)

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

drivers/amd/pm: fix a use-after-free in kvparsepower_table

When ps allocated by kzalloc equals to NULL, kvparsepower_table frees adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call chains:

kvparsepowertable |-> kvdpminit |-> kvdpmswinit |-> kvdpmfini

The adev->pm.dpm.ps is used in the for loop of kvdpmfini after its first free in kvparsepower_table and causes a use-after-free bug.(CVE-2023-52469)

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

perf/x86/lbr: Filter vsyscall addresses

We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top):

__insn_get_emulate_prefix()
insn_get_emulate_prefix()
insn_get_prefixes()
insn_get_opcode()
decode_branch_type()
get_branch_type()
intel_pmu_lbr_filter()
intel_pmu_handle_irq()
perf_event_nmi_handler()

Within _insngetemulateprefix() at frame 0, a macro is called:

peek_nbyte_next(insn_byte_t, insn, i)

Within this macro, this dereference occurs:

(insn)->next_byte

Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault.

To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region.(CVE-2023-52476)

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

net: nfc: fix races in nfcllcpsockget() and nfcllcpsockget_sn()

Sili Luo reported a race in nfcllcpsock_get(), leading to UAF.

Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock.

nfcllcpsockgetsn() has a similar problem.

Finally nfcllcprecvsnl() needs to make sure the socket found by nfcllcpsockfrom_sn() does not disappear.(CVE-2023-52502)

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

ravb: Fix use-after-free issue in ravbtxtimeout_work()

The ravbstop() should call cancelworksync(). Otherwise, ravbtxtimeoutwork() is possible to use the freed priv after ravb_remove() was called like below:

CPU0 CPU1 ravbtxtimeout() ravbremove() unregisternetdev() freenetdev(ndev) // free priv ravbtxtimeoutwork() // use priv

unregisternetdev() will call .ndostop() so that ravbstop() is called. And, after phystop() is called, netifcarrieroff() is also called. So that .ndotxtimeout() will not be called after phy_stop().(CVE-2023-52509)

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

jfs: fix array-index-out-of-bounds in diNewExt

[Syz report] UBSAN: array-index-out-of-bounds in fs/jfs/jfsimap.c:2360:2 index -878706688 is out of range for type 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2d0 lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:217 [inline] _ubsanhandleoutofbounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfsimap.c:2360 diAllocExt fs/jfs/jfsimap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfsimap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfsimap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfsinode.c:56 jfsmkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfsmkdir+0x2f1/0x4b0 fs/namei.c:4106 domkdirat+0x264/0x3a0 fs/namei.c:4129 _dosysmkdir fs/namei.c:4149 [inline] _sesysmkdir fs/namei.c:4147 [inline] _x64sysmkdir+0x6e/0x80 fs/namei.c:4147 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x45/0x110 arch/x86/entry/common.c:82 entrySYSCALL64afterhwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 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:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

[Analysis] When the agstart is too large, it can cause agno overflow.

[Fix] After obtaining agno, if the value is invalid, exit the subsequent process.

Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next report by kernel test robot (Dan Carpenter).(CVE-2023-52599)

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

jfs: fix uaf in jfsevictinode

When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcucore() calls jfsfree_node().

Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap.(CVE-2023-52600)

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

jfs: fix array-index-out-of-bounds in dbAdjTree

Currently there is a bound check missing in the dbAdjTree while accessing the dmtstree. To add the required check added the bool isctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/(CVE-2023-52601)

Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.(CVE-2024-23307)

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

net: qualcomm: rmnet: fix global oob in rmnet_policy

The variable rmnetlinkops assign a bigger maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. See bug trace below:

================================================================== BUG: KASAN: global-out-of-bounds in validatenla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in _nlavalidateparse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207

CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x8b/0xb3 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:284 [inline] printreport+0x172/0x475 mm/kasan/report.c:395 kasanreport+0xbb/0x1c0 mm/kasan/report.c:495 validatenla lib/nlattr.c:386 [inline] _nlavalidateparse+0x24af/0x2750 lib/nlattr.c:600 _nlaparse+0x3e/0x50 lib/nlattr.c:697 nlaparsenesteddeprecated include/net/netlink.h:1248 [inline] _rtnlnewlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnlnewlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlinkrcvmsg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlinkrcvskb+0x14f/0x410 net/netlink/afnetlink.c:2540 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x54e/0x800 net/netlink/afnetlink.c:1345 netlinksendmsg+0x930/0xe50 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0x154/0x190 net/socket.c:734 syssendmsg+0x6df/0x840 net/socket.c:2482 _syssendmsg+0x110/0x1b0 net/socket.c:2536 _syssendmsg+0xf3/0x1c0 net/socket.c:2565 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3b/0x90 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359 RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003 RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 </TASK>

The buggy address belongs to the variable: rmnet_policy+0x30/0xe0

The buggy address belongs to the physical page: page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9

According to the comment of nla_parse_nested_deprecated, the maxtype should be len(destination array) - 1. Hence use IFLA_RMNET_MAX here.(CVE-2024-26597)

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

phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP

If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example:

configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musbgadgetwakeup+0x1d4/0x254 [musbhdrc] ... musbgadgetwakeup [musbhdrc] from usbgadgetwakeup+0x1c/0x3c [udccore] usbgadgetwakeup [udccore] from ethstartxmit+0x3b0/0x3d4 [uether] ethstartxmit [uether] from devhardstartxmit+0x94/0x24c devhardstartxmit from schdirectxmit+0x104/0x2e4 schdirectxmit from _devqueuexmit+0x334/0xd88 _devqueuexmit from arpsolicit+0xf0/0x268 arpsolicit from neighprobe+0x54/0x7c neighprobe from _neigheventsend+0x22c/0x47c _neigheventsend from neighresolveoutput+0x14c/0x1c0 neighresolveoutput from ipfinishoutput2+0x1c8/0x628 ipfinishoutput2 from ipsendskb+0x40/0xd8 ipsendskb from udpsendskb+0x124/0x340 udpsendskb from udpsendmsg+0x780/0x984 udpsendmsg from _syssendto+0xd8/0x158 _syssendto from retfastsyscall+0x0/0x58

Let's fix the issue by checking for sendsrp() and setvbus() before calling them. For USB peripheral only cases these both could be NULL.(CVE-2024-26600)

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

binder: signal epoll threads of self-work

In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDERWRITEREAD without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards.

It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work.(CVE-2024-26606)

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

tomoyo: fix UAF write bug in tomoyowritecontrol()

Since tomoyowritecontrol() updates head->writebuf when write() of long lines is requested, we need to fetch head->writebuf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems.(CVE-2024-26622)

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

llc: call sock_orphan() at release time

syzbot reported an interesting trace [1] caused by a stale sk->sk_wq pointer in a closed llc socket.

In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after calling protoops::release()") Eric Biggers hinted that some protocols are missing a sockorphan(), we need to perform a full audit.

In net-next, I plan to clear sock->sk from sock_orphan() and amend Eric patch to add a warning.

[1] BUG: KASAN: slab-use-after-free in listempty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueueactive include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sockdefwritespacewfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27

CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xd9/0x1b0 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc4/0x620 mm/kasan/report.c:488 kasanreport+0xda/0x110 mm/kasan/report.c:601 listempty include/linux/list.h:373 [inline] waitqueueactive include/linux/wait.h:127 [inline] sockdefwritespacewfree net/core/sock.c:3384 [inline] sockwfree+0x9a8/0x9d0 net/core/sock.c:2468 skbreleaseheadstate+0xa3/0x2b0 net/core/skbuff.c:1080 skbreleaseall net/core/skbuff.c:1092 [inline] napiconsumeskb+0x119/0x2b0 net/core/skbuff.c:1404 e1000unmapandfreetxresource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000main.c:1970 e1000cleantxirq drivers/net/ethernet/intel/e1000/e1000main.c:3860 [inline] e1000clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000main.c:3801 _napipoll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napipoll net/core/dev.c:6645 [inline] netrxaction+0x956/0xe90 net/core/dev.c:6778 _dosoftirq+0x21a/0x8de kernel/softirq.c:553 runksoftirqd kernel/softirq.c:921 [inline] runksoftirqd+0x31/0x60 kernel/softirq.c:913 smpbootthreadfn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK>

Allocated by task 5167: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 unpoisonslabobject mm/kasan/common.c:314 [inline] _kasanslaballoc+0x81/0x90 mm/kasan/common.c:340 kasanslaballoc include/linux/kasan.h:201 [inline] slabpostallochook mm/slub.c:3813 [inline] slaballocnode mm/slub.c:3860 [inline] kmemcachealloclru+0x142/0x6f0 mm/slub.c:3879 allocinodesb include/linux/fs.h:3019 [inline] sockallocinode+0x25/0x1c0 net/socket.c:308 allocinode+0x5d/0x220 fs/inode.c:260 newinodepseudo+0x16/0x80 fs/inode.c:1005 sockalloc+0x40/0x270 net/socket.c:634 _sockcreate+0xbc/0x800 net/socket.c:1535 sockcreate net/socket.c:1622 [inline] _syssocketcreate net/socket.c:1659 [inline] _syssocket+0x14c/0x260 net/socket.c:1706 _dosyssocket net/socket.c:1720 [inline] _sesyssocket net/socket.c:1718 [inline] _x64syssocket+0x72/0xb0 net/socket.c:1718 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xd3/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

Freed by task 0: kasansavestack+0x33/0x50 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 kasansavefreeinfo+0x3f/0x60 mm/kasan/generic.c:640 poisonslabobject mm/kasan/common.c:241 [inline] _kasanslabfree+0x121/0x1b0 mm/kasan/common.c:257 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2121 [inlin ---truncated---(CVE-2024-26625)