The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/i915/gt: Cleanup partial engine discovery failures

If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated.

v2: - Drop the destroypinnedcontext() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz)(CVE-2022-48893)

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

f2fs: fix to avoid dirent corruption

As Al reported in link[1]:

f2fsrename() ... if (olddir != newdir && !whiteout) f2fssetlink(oldinode, olddirentry, olddirpage, newdir); else f2fsputpage(olddir_page, 0);

You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place.

[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/

With below testcase, it may cause dirent corruption, due to it missed to call f2fssetlink() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar

[ASSERT] (_chkdots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs Fail

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

efivarfs: force RO when remounting if SetVariable is not supported

If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this:

$ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK

[ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpmtis tpmtiscore crct10difce armsmccctrng rngcore drm fuse iptables xtables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivarsetvariablelocked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivarentrysetgetsize+0x98/0x16c [ 303.304585] efivarfsfilewrite+0xd0/0x1a4 [ 303.305148] vfswrite+0xc4/0x2e4 [ 303.305601] ksyswrite+0x70/0x104 [ 303.306073] _arm64syswrite+0x1c/0x28 [ 303.306622] invokesyscall+0x48/0x114 [ 303.307156] el0svccommon.constprop.0+0x44/0xec [ 303.307803] doel0svc+0x38/0x98 [ 303.308268] el0svc+0x2c/0x84 [ 303.308702] el0t64synchandler+0xf4/0x120 [ 303.309293] el0t64sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]---

Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime.(CVE-2023-52463)

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

x86/srso: Add SRSO mitigation for Hygon processors

Add mitigation for the speculative return stack overflow vulnerability which exists on Hygon processors too.(CVE-2023-52482)

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

crypto: scomp - fix req->dst buffer overflow

The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem.(CVE-2023-52612)

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

llc: verify mac len before reading mac header

LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header.

Syzbot was able to enter llcrcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tunpi header when not configuring IFFNOPI).

BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002

Add a maclen test before all three ethhdr(skb) calls under net/llc.

There are further uses in include/net/llcpdu.h. All these are protected by a test skb->protocol == ETHP8022. Which does not protect against this tun scenario.

But the maclen test added in this patch in llcfixupskb will indirectly protect those too. That is called from llcrcv before any other LLC code.

It is tempting to just add a blanket maclen check in llcrcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring.

At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.(CVE-2023-52843)

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

hvnetvsc: Register VF in netvscprobe if NETDEVICEREGISTER missed

If hvnetvsc driver is unloaded and reloaded, the NETDEVICEREGISTER handler cannot perform VF register successfully as the register call is received before netvscprobe is finished. This is because we register registernetdevicenotifier() very early( even before vmbusdriverregister()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvsc_probe.(CVE-2024-26820)

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

netfilter: nf_tables: honor table dormant flag from netdev release event path

Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook.

[524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 nfunregisternethook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanupnet [524854.858886] RIP: 0010:nfunregisternethook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] <TASK> [524854.859013] ? _warn+0x9f/0x1a0 [524854.859027] ? _nfunregisternethook+0x21a/0x260 [524854.859044] ? reportbug+0x1b1/0x1e0 [524854.859060] ? handlebug+0x3c/0x70 [524854.859071] ? excinvalidop+0x17/0x40 [524854.859083] ? asmexcinvalidop+0x1a/0x20 [524854.859100] ? _nfunregisternethook+0x6a/0x260 [524854.859116] ? _nfunregisternethook+0x21a/0x260 [524854.859135] nftablesnetdevevent+0x337/0x390 [nftables] [524854.859304] ? _pfxnftablesnetdevevent+0x10/0x10 [nftables] [524854.859461] ? packetnotifier+0xb3/0x360 [524854.859476] ? rawspinunlockirqrestore+0x11/0x40 [524854.859489] ? dcbnlnetdeviceevent+0x35/0x140 [524854.859507] ? _pfxnftablesnetdevevent+0x10/0x10 [nftables] [524854.859661] notifiercallchain+0x7d/0x140 [524854.859677] unregisternetdevicemany_notify+0x5e1/0xae0(CVE-2024-36005)

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

ext4: fix uninitialized ratelimitstate->lock access in _ext4fillsuper()

In the following concurrency we will access the uninitialized rs->lock:

ext4fillsuper ext4registersysfs // sysfs registered msgratelimitintervalms // Other processes modify rs->interval to // non-zero via msgratelimitintervalms ext4orphancleanup ext4msg(sb, KERNINFO, "Errors on filesystem, " ext4msg _ratelimit(&(EXT4SB(sb)->smsgratelimitstate) if (!rs->interval) // do nothing if interval is 0 return 1; rawspintrylockirqsave(&rs->lock, flags) rawspintrylock(lock) rawspintrylock _rawspintrylock spinacquire(&lock->depmap, 0, 1, RETIP) lockacquire _lockacquire registerlockclass assignlockkey dumpstack(); ratelimitstateinit(&sbi->smsgratelimitstate, 5 * HZ, 10); rawspinlock_init(&rs->lock); // init rs->lock here

and get the following dump_stack:

========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dumpstacklvl+0xc5/0x170 dumpstack+0x18/0x30 registerlockclass+0x740/0x7c0 lockacquire+0x69/0x13a0 lockacquire+0x120/0x450 _rawspintrylock+0x98/0xd0 _ratelimit+0xf6/0x220 _ext4msg+0x7f/0x160 [ext4] ext4orphancleanup+0x665/0x740 [ext4] _ext4fillsuper+0x21ea/0x2b10 [ext4] ext4fillsuper+0x14d/0x360 [ext4]

[...]

Normally interval is 0 until smsgratelimitstate is initialized, so _ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msgratelimitintervalms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.(CVE-2024-40998)

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

bpf: Take return from setmemoryrox() into account with bpfjitbinarylockro()

setmemoryrox() can fail, leaving memory unprotected.

Check return and bail out when bpfjitbinarylockro() returns an error.(CVE-2024-42067)

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

net: nexthop: Initialize all fields in dumped nexthops

struct nexthopgrp contains two reserved fields that are not initialized by nlaputnhgroup(), and carry garbage. This can be observed e.g. with strace (edited for clarity):

# ip nexthop add id 1 dev lo
# ip nexthop add id 101 group 1
# strace -e recvmsg ip nexthop get id 101
...
recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},
             [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52

The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure.(CVE-2024-42283)

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

irqchip/imx-irqsteer: Handle runtime power management correctly

The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing:

BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: _schedulebug+0x54/0x6c _schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedulepreemptdisabled+0x24/0x40 _mutexlock.constprop.0+0x2c0/0x540 _mutexlockslowpath+0x14/0x20 mutexlock+0x48/0x54 clkpreparelock+0x44/0xa0 clkprepare+0x20/0x44 imxirqsteerresume+0x28/0xe0 pmgenericruntimeresume+0x2c/0x44 _genpdruntimeresume+0x30/0x80 genpdruntimeresume+0xc8/0x2c0 _rpmcallback+0x48/0x1d8 rpmcallback+0x6c/0x78 rpmresume+0x490/0x6b4 _pmruntimeresume+0x50/0x94 irqchippmget+0x2c/0xa0 _irqdosethandler+0x178/0x24c irqsetchainedhandleranddata+0x60/0xa4 mxcgpio_probe+0x160/0x4b0

Cure this by implementing the irqbuslock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context.

tglx: Rewrote change log, added Fixes tag

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

udf: Avoid using corrupted block bitmap buffer

When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not.(CVE-2024-42306)

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

drm/gma500: fix null pointer dereference in psbintellvdsgetmodes

In psbintellvdsgetmodes(), the return value of drmmodeduplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drmmodeduplicate(). Add a check to avoid npd.(CVE-2024-42309)

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

media: venus: fix use after free in vdec_close

There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst.

Fix it by cancelling the work in vdec_close.(CVE-2024-42313)

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

ipvs: properly dereference pe in ipvsadd_service

Use pe directly to resolve sparse warning:

net/netfilter/ipvs/ipvsctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)

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

PCI: keystone: Fix NULL pointer dereference in case of DT error in kspciesetuprcapp_regs()

If IORESOURCEMEM is not provided in Device Tree due to any error, resourcelistfirsttype() will return NULL and pciparserequestofpci_ranges() will just emit a warning.

This will cause a NULL pointer dereference. Fix this bug by adding NULL return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)

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

leds: trigger: Unregister sysfs attributes before calling deactivate()

Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback.

Calling deviceremovegroups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data.

Move the deviceremovegroups() call to before deactivate() to close this race window.

This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling deviceaddgroups().(CVE-2024-43830)

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

bpf, arm64: Fix trampoline for BPFTRAMPFCALLORIG

When BPFTRAMPFCALLORIG is set, the trampoline calls _bpftrampenter() and _bpftrampexit() functions, passing them the struct bpftrampimage *im pointer as an argument in R0.

The trampoline generation code uses emitaddrmovi64() to emit instructions for moving the bpftrampimage address into R0, but emitaddrmovi64() assumes the address to be in the vmalloc() space and uses only 48 bits. Because bpftrampimage is allocated using kzalloc(), its address can use more than 48-bits, in this case the trampoline will pass an invalid address to _bpftramp_enter/exit() causing a kernel crash.

Fix this by using emita64movi64() in place of emitaddrmovi64() as it can work with addresses that are greater than 48-bits.(CVE-2024-43840)

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

md: fix deadlock between mddev_suspend and flush bio

Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue.

T1. the first flush is at the ending stage, it clears 'mddev->flushbio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flushbio', and attempts to queue mdsubmitflushdata(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc activeio and tries to flush, but is blocked because 'mddev->flushbio' is not NULL (set by T2). T4. mddevsuspend() is called and waits for active_io dec to 0 which is inc by T3.

T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) mdsubmitflushdata mddev->flushbio = NULL; . . mdflushrequest . mddev->flushbio = bio . queue submitflushes . . . . mdhandlerequest . . activeio + 1 . . mdflushrequest . . wait !mddev->flushbio . . . . mddevsuspend . . wait !activeio . . . submitflushes . queuework mdsubmitflushdata . //mdsubmitflushdata is already running (T1) . mdhandlerequest wait resume

The root issue is non-atomic inc/dec of activeio during flush process. activeio is dec before mdsubmitflushdata is queued, and inc soon after mdsubmitflushdata() run. mdflushrequest activeio + 1 submitflushes activeio - 1 mdsubmitflushdata mdhandlerequest activeio + 1 makerequest active_io - 1

If activeio is dec after mdhandlerequest() instead of within submitflushes(), makerequest() can be called directly intead of mdhandlerequest() in mdsubmitflushdata(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed.

Additionally, the only difference between fixing the issue and before is that there is no return error handling of makerequest(). But after previous patch cleaned mdwritestart(), makerequst() only return error in raid5makerequest() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, makerequest() will not be called in mdsubmitflushdata(). To prevent future modifications from introducing issues, add WARNON to ensure makerequest() no error is returned in this context.(CVE-2024-43855)

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

RDMA/hns: Fix soft lockup under heavy CEQE load

CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load.

Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler.(CVE-2024-43872)

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

memcg: protect concurrent access to memcgroupidr

Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the memcgroupidr, the idralloc() and idrreplace() happen within css callback and thus are protected through cgroupmutex from concurrent modifications. However idrremove() for memcgroupidr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that.

We have been seeing listlru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of listlru code including listlruadd(), listlrudel() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the superblock's listlru didn't have listlruone for the memcg of that object. The initial suspicions were either the object is not allocated through kmemcachealloclru() or somehow memcglistlrualloc() failed to allocate listlruone() for a memcg but returned success. No evidence were found for these cases.

Looking more deeply, we started seeing situations where valid memcg's id is not present in memcgroupidr and in some cases multiple valid memcgs have same id and memcgroupidr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idrremove() calls or race between idralloc()/idrreplace() and idrremove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup listlrus on the system for all of them. Later access from other memcgs to the listlru cause crashes due to missing listlruone.(CVE-2024-43892)

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

serial: core: check uartclk for zero to avoid divide by zero

Calling ioctl TIOCSSERIAL with an invalid baudbase can result in uartclk being zero, which will result in a divide by zero error in uartgetdivisor(). The check for uartclk being zero in uartset_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set.

Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uartgetdivisor (drivers/tty/serial/serialcore.c:580) Call Trace: <TASK> serial8250getdivisor (drivers/tty/serial/8250/8250port.c:2576 drivers/tty/serial/8250/8250port.c:2589) serial8250dosettermios (drivers/tty/serial/8250/8250port.c:502 drivers/tty/serial/8250/8250port.c:2741) serial8250settermios (drivers/tty/serial/8250/8250port.c:2862) uartchangelinesettings (./include/linux/spinlock.h:376 ./include/linux/serialcore.h:608 drivers/tty/serial/serialcore.c:222) uartportstartup (drivers/tty/serial/serialcore.c:342) uartstartup (drivers/tty/serial/serialcore.c:368) uartsetinfo (drivers/tty/serial/serialcore.c:1034) uartsetinfouser (drivers/tty/serial/serialcore.c:1059) ttysetserial (drivers/tty/ttyio.c:2637) ttyioctl (drivers/tty/ttyio.c:2647 drivers/tty/ttyio.c:2791) _x64sysioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) dosyscall64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Rule: add(CVE-2024-43893)

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

fou: remove warn in guegroreceive on unsupported protocol

Drop the WARNONONCE inn guegroreceive if the encapsulated type is not known or does not have a GRO handler.

Such a packet is easily constructed. Syzbot generates them and sets off this warning.

Remove the warning as it is expected and not actionable.

The warning was previously reduced from WARNON to WARNONONCE in commit 270136613bf7 ("fou: Do WARNONONCE in guegro_receive for bad proto callbacks").(CVE-2024-44940)

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

ALSA: line6: Fix racy access to midibuf

There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here).

This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.(CVE-2024-44954)

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

atm: idt77252: prevent use after free in dequeue_rx()

We can't dereference "skb" after calling vcc->push() because the skb is released.(CVE-2024-44998)

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

xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration

re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference.

Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usbep0reinit() in this case, which ends up calling xhciconfigureendpoint().

On Panther point xHC the xhciconfigureendpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware

If xHC address device command fails then a new xhcivirtdevice structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usbep0reinit() is called and xhciconfigureendpoint() tries to check and reserve bandwidth

[46710.713538] usb 3-1: new full-speed USB device number 5 using xhcihcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: errorcode(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.32 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usbhubwq hubevent [usbcore] [46711.125668] RIP: 0010:xhcireservebandwidth (drivers/usb/host/xhci.c

Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.(CVE-2024-45006)

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

s390/dasd: fix error recovery leading to data corruption on ESE devices

Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing.

The dasdeseneeds_format function checks for error codes that signal the non existence of a proper track format.

The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart.

Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode.

Also remove the check for file protected since this is not a valid ESE handling case.(CVE-2024-45026)

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

nfc: pn533: Add poll mod list filling check

In case of improtocols value is 1 and tmprotocols value is 0 this combination successfully passes the check 'if (!improtocols && !tmprotocols)' in the nfcstartpoll(). But then after pn533pollcreatemodlist() call in pn533startpoll() poll mod list will remain empty and dev->pollmodcount will remain 0 which lead to division by zero.

Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFCCMDSTARTPOLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->pollmodcount is not incremented inside pn533pollcreatemodlist(), thus leading to division by zero. Call trace looks like: nfcgenlstartpoll() nfcstartpoll() ->startpoll() pn533start_poll()

Add poll mod list filling check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)

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

usb: typec: ucsi: Fix null pointer dereference in trace

ucsiregisteraltmode checks ISERR for the alt pointer and treats NULL as valid. When CONFIGTYPECDPALTMODE is not enabled, ucsiregisterdisplayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typecportregisteraltmode to register DisplayPort alternate mode as a non-controllable mode when CONFIGTYPECDPALTMODE is not enabled.(CVE-2024-46719)

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

bpf: Remove tstrun from lwtseg6localprogops.

The syzbot reported that the lwtseg6 related BPF ops can be invoked via bpftestrun() without without entering inputactionendbpf() first.

Martin KaFai Lau said that self test for BPFPROGTYPELWTSEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6bpfsrh_states::srh is never assigned in the self test case but each BPF function expects it.

Remove testrun for BPFPROGTYPELWT_SEG6LOCAL.(CVE-2024-46754)

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

ice: Add netifdeviceattach/detach into PF reset flow

Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below.

Reproduction steps: Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net/<interface>/device/reset when reset is in progress try to get coalesce settings using ethtool: # ethtool -c <interface>

BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:icegetqcoalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: <TASK> icegetcoalesce+0x17/0x30 [ice] coalescepreparedata+0x61/0x80 ethnldefaultdoit+0xde/0x340 genlfamilyrcvmsgdoit+0xf2/0x150 genlrcvmsg+0x1b3/0x2c0 netlinkrcvskb+0x5b/0x110 genlrcv+0x28/0x40 netlinkunicast+0x19c/0x290 netlinksendmsg+0x222/0x490 _syssendto+0x1df/0x1f0 _x64syssendto+0x24/0x30 dosyscall64+0x82/0x160 entrySYSCALL64after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27

Calling netifdevicedetach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message:

netlink error: No such device

instead of NULL pointer dereference. Once reset is done and icerebuild() is executing, the netifdevice_attach() is called to allow for ethtool operations to occur again in a safe manner.(CVE-2024-46770)

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

ksmbd: unset the binding mark of a reused connection

Steve French reported null pointer dereference error from sha256 lib. cifs.ko can send session setup requests on reused connection. If reused connection is used for binding session, conn->binding can still remain true and generatepreauthhash() will not set sess->PreauthHashValue and it will be NULL. It is used as a material to create an encryption key in ksmbdgensmb311encryptionkey. ->PreauthHashValue cause null pointer dereference error from cryptoshash_update().

BUG: kernel NULL pointer dereference, address: 0000000000000000

PF: supervisor read access in kernel mode

PF: error_code(0x0000) - not-present page

PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 8 PID: 429254 Comm: kworker/8:39 Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 ) Workqueue: ksmbd-io handleksmbdwork [ksmbd] RIP: 0010:libsha256basedoupdate.isra.0+0x11e/0x1d0 [sha256ssse3] <TASK> ? showregs+0x6d/0x80 ? _die+0x24/0x80 ? pagefaultoops+0x99/0x1b0 ? douseraddrfault+0x2ee/0x6b0 ? excpagefault+0x83/0x1b0 ? asmexcpagefault+0x27/0x30 ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] ? libsha256basedoupdate.isra.0+0x11e/0x1d0 [sha256ssse3] ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] ? _pfxsha256transformrorx+0x10/0x10 [sha256ssse3] _sha256update+0x77/0xa0 [sha256ssse3] sha256avx2update+0x15/0x30 [sha256ssse3] cryptoshashupdate+0x1e/0x40 hmacupdate+0x12/0x20 cryptoshashupdate+0x1e/0x40 generatekey+0x234/0x380 [ksmbd] generatesmb3encryptionkey+0x40/0x1c0 [ksmbd] ksmbdgensmb311encryptionkey+0x72/0xa0 [ksmbd] ntlmauthenticate.isra.0+0x423/0x5d0 [ksmbd] smb2sesssetup+0x952/0xaa0 [ksmbd] _processrequest+0xa3/0x1d0 [ksmbd] _handleksmbdwork+0x1c4/0x2f0 [ksmbd] handleksmbdwork+0x2d/0xa0 [ksmbd] processonework+0x16c/0x350 workerthread+0x306/0x440 ? _pfxworkerthread+0x10/0x10 kthread+0xef/0x120 ? _pfxkthread+0x10/0x10 retfromfork+0x44/0x70 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1b/0x30 </TASK>(CVE-2024-46795)

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

drm/amdgpu: the warning dereferencing obj for nbiov74

if ras_manager obj null, don't print NBIO err data(CVE-2024-46819)

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

ELF: fix kernel.randomizevaspace double read

ELF loader uses "randomizevaspace" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences.

Issue exactly one load for consistent value across one exec.(CVE-2024-46826)

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

sched: sch_cake: fix bulk flow accounting logic for host fairness

In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state.

This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again).

Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the increment was made conditional, but the decrement was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX).

AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right.

This patch fixes the issue by introducing the same conditional check on decrement as is used on increment.

The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that.(CVE-2024-46828)

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

btrfs: clean up our handling of refs == 0 in snapshot delete

In reada we BUGON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walkdownproc we also BUGON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In dowalkdown() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walkupproc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.(CVE-2024-46840)

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

perf/x86/intel: Limit the period on Haswell

Running the ltp test cve-2015-3290 concurrently reports the following warnings.

perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intelpmuhandleirq+0x285/0x370 Call Trace: <NMI> ? _warn+0xa4/0x220 ? intelpmuhandleirq+0x285/0x370 ? _reportbug+0x123/0x130 ? intelpmuhandleirq+0x285/0x370 ? _reportbug+0x123/0x130 ? intelpmuhandleirq+0x285/0x370 ? reportbug+0x3e/0xa0 ? handlebug+0x3c/0x70 ? excinvalidop+0x18/0x50 ? asmexcinvalidop+0x1a/0x20 ? irqworkclaim+0x1e/0x40 ? intelpmuhandleirq+0x285/0x370 perfeventnmihandler+0x3d/0x60 nmi_handle+0x104/0x330

Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)

The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW.

HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far.(CVE-2024-46848)

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

net: dpaa: Pad packets to ETH_ZLEN

When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running

$ ping -s 11 destination(CVE-2024-46854)

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

netfilter: nft_socket: fix sk refcount leaks

We must put 'sk' reference before returning.(CVE-2024-46855)

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

mptcp: pm: Fix uaf in _timerdelete_sync

There are two paths to access mptcppmdeladdtimer, result in a race condition:

 CPU1               CPU2
 ====                               ====
 net_rx_action
 napi_poll                          netlink_sendmsg
 __napi_poll                        netlink_unicast
 process_backlog                    netlink_unicast_kernel
 __netif_receive_skb                genl_rcv
 __netif_receive_skb_one_core       netlink_rcv_skb
 NF_HOOK                            genl_rcv_msg
 ip_local_deliver_finish            genl_family_rcv_msg
 ip_protocol_deliver_rcu            genl_family_rcv_msg_doit
 tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit
 tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list
 tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows
 tcp_data_queue                     remove_anno_list_by_saddr
 mptcp_incoming_options             mptcp_pm_del_add_timer
 mptcp_pm_del_add_timer             kfree(entry)

In removeannolistbysaddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcppmdeladdtimer(running on CPU1).

Keeping a reference to addtimer inside the lock, and calling skstoptimersync() with this reference, instead of "entry->add_timer".

Move listdel(&entry->list) to mptcppmdeladd_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf.(CVE-2024-46858)

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

crypto: stm32/cryp - call finalize with bh disabled

The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.(CVE-2024-47658)

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

spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware

If the value of maxspeedhz is 0, it may cause a division by zero error in hisicalceffectivespeed(). The value of maxspeedhz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of maxspeed is validated here. So 0 is regarded as invalid and an error code is returned.(CVE-2024-47664)

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

ocfs2: add bounds checking to ocfs2xattrfind_entry()

Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images.(CVE-2024-47670)

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

USB: usbtmc: prevent kernel-usb-infoleak

The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.(CVE-2024-47671)

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

wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead

There is a WARNING in iwltranswaittxqueues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead.

Don't call iwltranswaittxqueues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running.

edit commit message