OESA-2024-1993

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

media: mediatek: vcodec: Only free buffer VA that is not NULL

In the MediaTek vcodec driver, while mtkvcodecmem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice.

We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings.(CVE-2023-52888)

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:

dmaengine: idxd: Fix possible Use-After-Free in irqprocesswork_list

Use listforeachentrysafe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxddesccomplete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list.(CVE-2024-40956)

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

RDMA/mlx5: Add check for srq max_sge attribute

max_sge attribute is passed by the user, and is inserted and used unchecked, so verify that the value doesn't exceed maximum allowed value before using it.(CVE-2024-40990)

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:

netfilter: nftables: prefer nftchain_validate

nftchainvalidate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFTJUMPSTACK_SIZE).

It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again.

nftablescheck_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s.

This also fixes a crash bug. Old loop detection code can result in unbounded recursion:

BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..]

with a suitable ruleset during validation of register stores.

I can't see any actual reason to attempt to check for this from nftvalidateregister_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph.

For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).(CVE-2024-41042)

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:

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:

wifi: cfg80211: restrict NL80211ATTRTXQ_QUANTUM values

syzbot is able to trigger softlockups, setting NL80211ATTRTXQ_QUANTUM to 2^31.

We had a similar issue in schfq, fixed with commit d9e15a273306 ("pktsched: fq: do not accept silly TCAFQQUANTUM")

watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [<ffff80008ae8778c>] _exittokernelmode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [<ffff80008ae8778c>] exittokernelmode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [<ffff80008ae85378>] _el1irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [<ffff80008ae85378>] el1interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [<ffff80008907e82c>] neighhhinit net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [<ffff80008907e82c>] neighresolveoutput+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [<ffff80008904166c>] localbhdisable+0x10/0x34 include/linux/bottomhalf.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mldifcwork pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _listdel include/linux/list.h:195 [inline] pc : _listdelentry include/linux/list.h:218 [inline] pc : listmovetail include/linux/list.h:310 [inline] pc : fqtindequeue include/net/fqimpl.h:112 [inline] pc : ieee80211txdequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : _listdelentry include/linux/list.h:218 [inline] lr : listmovetail include/linux/list.h:310 [inline] lr : fqtindequeue include/net/fqimpl.h:112 [inline] lr : ieee80211txdequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: _listdel include/linux/list.h:195 [inline] _listdelentry include/linux/list.h:218 [inline] listmovetail include/linux/list.h:310 [inline] fqtindequeue include/net/fqimpl.h:112 [inline] ieee80211txdequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 waketxpushqueue net/mac80211/util.c:294 [inline] ieee80211handlewaketxqueue+0x118/0x274 net/mac80211/util.c:315 drvwaketxqueue net/mac80211/driver-ops.h:1350 [inline] scheduleandwaketxq net/mac80211/driver-ops.h:1357 [inline] ieee80211queueskb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211xmit+0x278/0x354 net/mac80211/tx.c:2062 _ieee80211subifstartxmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211subifstartxmit+0xe0/0x438 net/mac80211/tx.c:4532 _netdevstartxmit include/linux/netdevice.h:4903 [inline] netdevstartxmit include/linux/netdevice.h:4917 [inline] xmitone net/core/dev.c:3531 [inline] devhardstartxmit+0x27c/0x938 net/core/dev.c:3547 _devqueuexmit+0x1678/0x33fc net/core/dev.c:4341 devqueuexmit include/linux/netdevice.h:3091 [inline] neighresolveoutput+0x558/0x658 net/core/neighbour.c:1563 neighoutput include/net/neighbour.h:542 [inline] ip6_fini ---truncated---(CVE-2024-42114)

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

s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings

Replace memzeroexplicit() and kfree() with kfreesensitive() to fix warnings reported by Coccinelle:

WARNING opportunity for kfreesensitive/kvfreesensitive (line 1506) WARNING opportunity for kfreesensitive/kvfreesensitive (line 1643) WARNING opportunity for kfreesensitive/kvfreesensitive (line 1770)(CVE-2024-42158)

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)