OESA-2024-1996

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ethernet: Fix error handling in xemacliteofprobe

This node pointer is returned by ofparsephandle() with refcount incremented in this function. Calling ofnodeput() to avoid the refcount leak. As the remove function do.(CVE-2022-48860)

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

HID: core: remove unnecessary WARN_ON() in implement()

Syzkaller hit a warning [1] in a call to implement() when trying to write a value into a field of smaller size in an output report.

Since implement() already has a warn message printed out with the help of hidwarn() and value in question gets trimmed with: ... value &= m; ... WARNON may be considered superfluous. Remove it to suppress future syzkaller triggers.

[1] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hidoutputreport+0x548/0x760 drivers/hid/hid-core.c:1863 Modules linked in: CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline] RIP: 0010:hidoutputreport+0x548/0x760 drivers/hid/hid-core.c:1863 ... Call Trace: <TASK> _usbhidsubmitreport drivers/hid/usbhid/hid-core.c:591 [inline] usbhidsubmitreport+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddevioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:904 [inline] _sesysioctl+0xfc/0x170 fs/ioctl.c:890 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f ...(CVE-2024-39509)

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

filelock: Remove locks reliably when fcntl/close race is detected

When fcntlsetlk() races with close(), it removes the created lock with dolockfilewait(). However, LSMs can allow the first dolockfilewait() that created the lock while denying the second dolockfilewait() that tries to remove the lock. Separately, posixlockfile() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle).

After the bug has been triggered, use-after-free reads will occur in lockgetstatus() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory.

Fix it by calling locksremoveposix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and filesstruct and is also used by filpflush().(CVE-2024-41012)

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

nilfs2: fix kernel bug on rename operation of broken directory

Syzbot reported that in rename directory operation on broken directory on nilfs2, _blockwritebeginint() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size.

This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories.

Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)

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

USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor

Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpointisduplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk).

To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usbparseendpoint() and use the copy instead of the original when checking for duplicates.(CVE-2024-41035)

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

net: ethernet: lantiq_etop: fix double free in detach

The number of the currently released descriptor is never incremented which results in the same skb being released multiple times.(CVE-2024-41046)

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

hfsplus: fix uninit-value in copy_name

[syzbot reported] BUG: KMSAN: uninit-value in sizedstrscpy+0xc4/0x160 sizedstrscpy+0xc4/0x160 copyname+0x2af/0x320 fs/hfsplus/xattr.c:411 hfspluslistxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfslistxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 pathlistxattr fs/xattr.c:864 [inline] _dosyslistxattr fs/xattr.c:876 [inline] _sesyslistxattr fs/xattr.c:873 [inline] _x64syslistxattr+0x16b/0x2f0 fs/xattr.c:873 x64syscall+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls64.h:195 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:3877 [inline] slaballocnode mm/slub.c:3918 [inline] kmalloctrace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfspluslistxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfslistxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 pathlistxattr fs/xattr.c:864 [inline] _dosyslistxattr fs/xattr.c:876 [inline] _sesyslistxattr fs/xattr.c:873 [inline] _x64syslistxattr+0x16b/0x2f0 fs/xattr.c:873 x64syscall+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls64.h:195 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0.(CVE-2024-41059)

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

powerpc/pseries: Whitelist dtl slub object for copying to userspace

Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIGHARDENEDUSERCOPY is enabled as shown below.

kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
NIP:  c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
REGS: c000000120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)
MSR:  8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 2828220f  XER: 0000000e
CFAR: c0000000001fdc80 IRQMASK: 0
[ ... GPRs omitted ... ]
NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
Call Trace:
 usercopy_abort+0x74/0xb0 (unreliable)
 __check_heap_object+0xf8/0x120
 check_heap_object+0x218/0x240
 __check_object_size+0x84/0x1a4
 dtl_file_read+0x17c/0x2c4
 full_proxy_read+0x8c/0x110
 vfs_read+0xdc/0x3a0
 ksys_read+0x84/0x144
 system_call_exception+0x124/0x330
 system_call_vectored_common+0x15c/0x2ec
--- interrupt: 3000 at 0x7fff81f3ab34

Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIGHARDENEDUSERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCHLOGBYTES to whitelist the entire object.(CVE-2024-41065)

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

ata: libata-core: Fix double free on error

If e.g. the ataportalloc() call in atahostalloc() fails, we will jump to the errout label, which will call devresreleasegroup(). devresreleasegroup() will trigger a call to atahostrelease(). atahostrelease() calls kfree(host), so executing the kfree(host) in atahost_alloc() will lead to a double free:

kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? _diebody.cold+0x19/0x27 ? die+0x2e/0x50 ? dotrap+0xca/0x110 ? doerrortrap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? excinvalidop+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asmexcinvalidop+0x1a/0x20 ? atahostalloc+0xf5/0x120 [libata] ? atahostalloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 atahostalloc+0xf5/0x120 [libata] atahostallocpinfo+0x14/0xa0 [libata] ahciinit_one+0x6c9/0xd20 [ahci]

Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devresopengroup() call failed.(CVE-2024-41087)

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

ftruncate: pass a signed offset

The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB.

Changing the type of the compat syscall to the signed compatofft changes the behavior so it instead returns -EINVAL.

The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake.(CVE-2024-42084)

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

drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep

The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiodsetvalue() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiodsetvalue_cansleep() to fix the issue.(CVE-2024-42087)

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

ASoC: fsl-asoc-card: set priv->pdev before using it

priv->pdev pointer was set after being used in fslasoccardaudmuxinit(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv.

fslasoccardaudmuxinit() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations.(CVE-2024-42089)

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

x86: stop playing stack games in profile_pc()

The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid.

Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days.

And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say:

Assume the lock function has either no stack frame or a copy
of eflags from PUSHF.

which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc:

Eflags always has bits 22 and up cleared unlike kernel addresses

but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame.

It causes KASAN unhappiness reported for years by syzkaller [1] and others [2].

With no real practical reason for this any more, just remove the code.

Just for historical interest, here's some background commits relating to this code from 2006:

0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")

and a code unification from 2009:

ef4512882dbe ("x86: time32/64.c unify profilepc")

but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)

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

Revert "mm/writeback: fix possible divide-by-zero in wbdirtylimits(), again"

Patch series "mm: Avoid possible overflows in dirty throttling".

Dirty throttling logic assumes dirty limits in page units fit into 32-bits. This patch series makes sure this is true (see patch 2/2 for more details).

This patch (of 2):

This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.

The commit is broken in several ways. Firstly, the removed (u64) cast from the multiplication will introduce a multiplication overflow on 32-bit archs if wbthresh * bgthresh >= 1<<32 (which is actually common - the default settings with 4GB of RAM will trigger this). Secondly, the div64u64() is unnecessarily expensive on 32-bit archs. We have div64ul() in case we want to be safe & cheap. Thirdly, if dirty thresholds are larger than 1<<32 pages, then dirty balancing is going to blow up in many other spectacular ways anyway so trying to fix one possible overflow is just moot.(CVE-2024-42102)

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

nilfs2: fix inode number range checks

Patch series "nilfs2: fix potential issues related to reserved inodes".

This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value.

This patch (of 3):

In the current implementation of nilfs2, "nilfs->nsfirstino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked.

As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFSMDTINODE and NILFSVALIDINODE) will not function properly.

In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "nsfirstino" is set to a large value other than the default value NILFSUSERINO (=11), the macros may potentially malfunction depending on the environment.

Fix these issues by checking the lower bound of "nilfs->nsfirstino" and by preventing bit shifts equal to or greater than the NILFSUSERINO constant in the inode number test macros.

Also, change the type of "nsfirstino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.(CVE-2024-42105)

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

orangefs: fix out-of-bounds fsid access

Arnd Bergmann sent a patch to fsdevel, he says:

"orangefs_statfs() copies two consecutive fields of the superblock into the statfs structure, which triggers a warning from the string fortification helpers"

Jan Kara suggested an alternate way to do the patch to make it more readable.

I ran both ideas through xfstests and both seem fine. This patch is based on Jan Kara's suggestion.(CVE-2024-42143)

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

bnx2x: Fix multiple UBSAN array-index-out-of-bounds

Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FPSBMAXE1x using the numqueues module parameter.

Currently there is a read/write out of bounds that occurs on the array "struct statsqueryentry query" present inside the "bnx2xfwstatsreq" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct statsquery_entry query" array:

struct statsqueryentry query[FPSBMAXE1x+ BNX2XFIRSTQUEUEQUERY_IDX];

FPSBMAXE1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2XFIRSTQUEUEQUERYIDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct statsqueryentry query" are offset-ted by BNX2XFIRSTQUEUEQUERYIDX, that means that the total number of Ethernet queues should not exceed FPSBMAXE1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FPSBMAXE1x -1] (15) if FCOE is enabled or [FPSBMAXE1x] (16) if it is not.

This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FPSBMAX_E1x. Below is the part of this explanation that it important for this patch

/* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */

However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FPSBMAXE2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FPSBMAXE2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "statsqueryentry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below.

This patch increases the size of the "statsqueryentry query" array by replacing FPSBMAXE1x with FPSBMAXE2 to be large enough to handle both types of NICs.

Stack traces:

UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2xstats.c:1529:11 index 20 is out of range for type 'statsquery_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---(CVE-2024-42148)

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

tcp_metrics: validate source addr length

I don't see anything checking that TCPMETRICSATTRSADDRIPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).(CVE-2024-42154)

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

s390/pkey: Wipe sensitive data on failure

Wipe sensitive data from stack also if the copytouser() fails.(CVE-2024-42157)

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

f2fs: check validation of fault attrs in f2fsbuildfault_attr()

• It missed to check validation of fault attrs in parseoptions(), let's fix to add check condition in f2fsbuildfaultattr().
• Use f2fsbuildfaultattr() in _sbi_store() to clean up code.(CVE-2024-42160)

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

media: dvb-frontends: tda10048: Fix integer overflow

state->xtalhz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pllmfactor.

Create a new 64 bit variable to hold the calculations.(CVE-2024-42223)

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

USB: serial: mos7840: fix crash on resume

Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one.

This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure.

Fix this by implementing dedicated suspend and resume functions for mos7840.

Tested with Delock 87414 USB 2.0 to 4x serial adapter.

johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usbkillurb()