OESA-2024-1736

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

PCI: aardvark: Fix kernel panic during PIO transfer

Trying to start a new PIO transfer by writing value 0 in PIOSTART register when previous transfer has not yet completed (which is indicated by value 1 in PIOSTART) causes an External Abort on CPU, which results in kernel panic:

SError Interrupt on CPU0, code 0xbf000002 -- SError
Kernel panic - not syncing: Asynchronous SError Interrupt

To prevent kernel panic, it is required to reject a new PIO transfer when previous one has not finished yet.

If previous PIO transfer is not finished yet, the kernel may issue a new PIO request only if the previous PIO transfer timed out.

In the past the root cause of this issue was incorrectly identified (as it often happens during link retraining or after link down event) and special hack was implemented in Trusted Firmware to catch all SError events in EL3, to ignore errors with code 0xbf000002 and not forwarding any other errors to kernel and instead throw panic from EL3 Trusted Firmware handler.

Links to discussion and patches about this issue: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50 https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/ https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/ https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

But the real cause was the fact that during link retraining or after link down event the PIO transfer may take longer time, up to the 1.44s until it times out. This increased probability that a new PIO transfer would be issued by kernel while previous one has not finished yet.

After applying this change into the kernel, it is possible to revert the mentioned TF-A hack and SError events do not have to be caught in TF-A EL3.(CVE-2021-47229)

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

phy: phy-mtk-tphy: Fix some resource leaks in mtkphyinit()

Use clkdisableunprepare() in the error path of mtkphyinit() to fix some resource leaks.(CVE-2021-47234)

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

net: rds: fix memory leak in rds_recvmsg

Syzbot reported memory leak in rds. The problem was in unputted refcount in case of error.

int rdsrecvmsg(struct socket *sock, struct msghdr *msg, sizet size, int msg_flags) { ...

if (!rds_next_incoming(rs, &inc)) {
    ...
}

After this "if" inc refcount incremented and

if (rds_cmsg_recv(inc, msg, rs)) {
    ret = -EFAULT;
    goto out;
}

... out: return ret; }

in case of rdscmsgrecv() fail the refcount won't be decremented. And it's easy to see from ftrace log, that rdsincaddref() don't have rdsincput() pair in rdsrecvmsg() after rdscmsg_recv()

1) | rdsrecvmsg() { 1) 3.721 us | rdsincaddref(); 1) 3.853 us | rdsmessageinccopytouser(); 1) + 10.395 us | rdscmsgrecv(); 1) + 34.260 us | }(CVE-2021-47249)

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

net: ieee802154: fix null deref in parse dev addr

Fix a logic error that could result in a null deref if the user sets the mode incorrectly for the given addr type.(CVE-2021-47257)

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

usb: fix various gadget panics on 10gbps cabling

usbassigndescriptors() is called with 5 parameters, the last 4 of which are the usbdescriptorheader for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps).

The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough).

However if a gadget driver calls usbassigndescriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it)

The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided.

Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way).(CVE-2021-47267)

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

ALSA: seq: Fix race of sndseqtimer_open()

The timer instance per queue is exclusive, and sndseqtimeropen() should have managed the concurrent accesses. It looks as if it's checking the already existing timer instance at the beginning, but it's not right, because there is no protection, hence any later concurrent call of sndseqtimeropen() may override the timer instance easily. This may result in UAF, as the leftover timer instance can keep running while the queue itself gets closed, as spotted by syzkaller recently.

For avoiding the race, add a proper check at the assignment of tmr->timeri again, and return -EBUSY if it's been already registered.(CVE-2021-47281)

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

igb: Fix use-after-free error during reset

Cleans the next descriptor to watch (nexttowatch) when cleaning the TX ring.

Failure to do so can cause invalid memory accesses. If igb_poll() runs while the controller is reset this can lead to the driver try to free a skb that was already freed.

(The crash is harder to reproduce with the igb driver, but the same potential problem exists as the code is identical to igc)(CVE-2021-47301)

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

net: ti: fix UAF in tlanremoveone

priv is netdev private data and it cannot be used after freenetdev() call. Using priv after freenetdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.(CVE-2021-47310)

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

watchdog: Fix possible use-after-free by calling deltimersync()

This driver's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free.

Fix by calling deltimersync(), which makes sure the timer handler has finished, and unable to re-schedule itself.(CVE-2021-47321)

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

misc/libmasm/module: Fix two use after free in ibmasminitone

In ibmasminitone, it calls ibmasminitremoteinputdev(). Inside ibmasminitremoteinputdev, mousedev and keybddev are allocated by inputallocatedevice(), and assigned to sp->remote.mousedev and sp->remote.keybddev respectively.

In the errfreedevices error branch of ibmasminitone, mousedev and keybddev are freed by inputfreedevice(), and return error. Then the execution runs into errorsendmessage error branch of ibmasminitone, where ibmasmfreeremoteinputdev(sp) is called to unregister the freed sp->remote.mousedev and sp->remote.keybddev.

My patch add a "errorinitremote" label to handle the error of ibmasminitremoteinputdev(), to avoid the uaf bugs.(CVE-2021-47334)

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

media: zr364xx: fix memory leak in zr364xxstartreadpipe

syzbot reported memory leak in zr364xx driver. The problem was in non-freed urb in case of usbsubmiturb() fail.

backtrace: [<ffffffff82baedf6>] kmalloc include/linux/slab.h:561 [inline] [<ffffffff82baedf6>] usballocurb+0x66/0xe0 drivers/usb/core/urb.c:74 [<ffffffff82f7cce8>] zr364xxstartreadpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [<ffffffff84251dfc>] zr364xxboardinit drivers/media/usb/zr364xx/zr364xx.c:1383 [inline] [<ffffffff84251dfc>] zr364xxprobe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516 [<ffffffff82bb6507>] usbprobeinterface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff826018a9>] reallyprobe+0x159/0x500 drivers/base/dd.c:576(CVE-2021-47344)

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

drm/sched: Avoid data corruptions

Wait for all dependencies of a job to complete before killing it to avoid data corruptions.(CVE-2021-47354)

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

net: macb: fix use after free on rmmod

platdev->dev->platformdata is released by platformdeviceunregister(), use of pclk and hclk is a use-after-free. Since device unregister won't need a clk device we adjust the function call sequence to fix this issue.

[ 31.261225] BUG: KASAN: use-after-free in macbremove+0x77/0xc6 [macbpci] [ 31.275563] Freed by task 306: [ 30.276782] platformdevicerelease+0x25/0x80(CVE-2021-47372)

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

i2c: acpi: fix resource leak in reconfiguration device addition

acpii2cfindadapterbyhandle() calls busfind_device() which takes a reference on the adapter which is never released which will result in a reference count leak and render the adapter unremovable. Make sure to put the adapter after creating the client in the same manner that we do for OF.

wsa: fixed title

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

net: encx24j600: check error in devmregmapinit_encx24j600

devmregmapinit may return error which caused by like out of memory, this will results in null pointer dereference later when reading or writing register:

general protection fault in encx24j600spiprobe KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:regcachecachebypass drivers/base/regmap/regcache.c:540 Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000 RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: encx24j600spiprobe drivers/net/ethernet/microchip/encx24j600.c:459 spiprobe drivers/spi/spi.c:397 reallyprobe drivers/base/dd.c:517 _driverprobedevice drivers/base/dd.c:751 driverprobedevice drivers/base/dd.c:782 _deviceattachdriver drivers/base/dd.c:899 busforeachdrv drivers/base/bus.c:427 _deviceattach drivers/base/dd.c:971 busprobedevice drivers/base/bus.c:487 deviceadd drivers/base/core.c:3364 _spiadddevice drivers/spi/spi.c:599 spiadddevice drivers/spi/spi.c:641 spinewdevice drivers/spi/spi.c:717 newdevicestore+0x18c/0x1f1 [spistub 4e02719357f1ff33f5a43d00630982840568e85e] devattrstore drivers/base/core.c:2074 sysfskfwrite fs/sysfs/file.c:139 kernfsfopwriteiter fs/kernfs/file.c:300 newsyncwrite fs/readwrite.c:508 (discriminator 4) vfswrite fs/readwrite.c:594 ksyswrite fs/readwrite.c:648 dosyscall64 arch/x86/entry/common.c:50 entrySYSCALL64afterhwframe arch/x86/entry/entry_64.S:113

Add error check in devmregmapinit_encx24j600 to avoid this situation.(CVE-2021-47440)

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

can: peakpci: peakpci_remove(): fix UAF

When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF.

Fix this by releasing 'dev' later.

The following log reveals it:

[ 35.961814 ] BUG: KASAN: use-after-free in peakpciremove+0x16f/0x270 [peakpci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dumpstacklvl+0xa8/0xd1 [ 35.966028 ] printaddressdescription+0x87/0x3b0 [ 35.966420 ] kasanreport+0x172/0x1c0 [ 35.966725 ] ? peakpciremove+0x16f/0x270 [peakpci] [ 35.967137 ] ? traceirqenablercuidle+0x10/0x170 [ 35.967529 ] ? peakpciremove+0x16f/0x270 [peakpci] [ 35.967945 ] _asanreportload8noabort+0x14/0x20 [ 35.968346 ] peakpciremove+0x16f/0x270 [peakpci] [ 35.968752 ] pcideviceremove+0xa9/0x250(CVE-2021-47456)

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

isdn: mISDN: Fix sleeping function called from invalid context

The driver can call card->isac.release() function from an atomic context.

Fix this by calling this function after releasing the lock.

The following log reveals it:

[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018 [ 44.168941 ] inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 5475, name: modprobe [ 44.169574 ] INFO: lockdep is turned off. [ 44.169899 ] irq event stamp: 0 [ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copyprocess+0x132d/0x3e00 [ 44.171240 ] softirqs last enabled at (0): [<ffffffff81420a1a>] copyprocess+0x135a/0x3e00 [ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 44.172318 ] Preemption disabled at: [ 44.172320 ] [<ffffffffa009b0a9>] njrelease+0x69/0x500 [netjet] [ 44.174441 ] Call Trace: [ 44.174630 ] dumpstacklvl+0xa8/0xd1 [ 44.174912 ] dumpstack+0x15/0x17 [ 44.175166 ] mightsleep+0x3a2/0x510 [ 44.175459 ] ? njrelease+0x69/0x500 [netjet] [ 44.175791 ] _mightsleep+0x82/0xe0 [ 44.176063 ] ? startflushwork+0x20/0x7b0 [ 44.176375 ] startflushwork+0x33/0x7b0 [ 44.176672 ] ? traceirqenablercuidle+0x85/0x170 [ 44.177034 ] ? kasanquarantineput+0xaa/0x1f0 [ 44.177372 ] ? kasanquarantineput+0xaa/0x1f0 [ 44.177711 ] _flushwork+0x11a/0x1a0 [ 44.177991 ] ? flushwork+0x20/0x20 [ 44.178257 ] ? lockrelease+0x13c/0x8f0 [ 44.178550 ] ? _kasancheckwrite+0x14/0x20 [ 44.178872 ] ? dorawspinlock+0x148/0x360 [ 44.179187 ] ? readlockisrecursive+0x20/0x20 [ 44.179530 ] ? _kasancheckread+0x11/0x20 [ 44.179846 ] ? dorawspinunlock+0x55/0x900 [ 44.180168 ] ? kasanslabfree+0x116/0x140 [ 44.180505 ] ? rawspinunlockirqrestore+0x41/0x60 [ 44.180878 ] ? skbqueuepurge+0x1a3/0x1c0 [ 44.181189 ] ? kfree+0x13e/0x290 [ 44.181438 ] flushwork+0x17/0x20 [ 44.181695 ] mISDNfreedchannel+0xe8/0x100 [ 44.182006 ] isacrelease+0x210/0x260 [mISDNipac] [ 44.182366 ] njrelease+0xf6/0x500 [netjet] [ 44.182685 ] njremove+0x48/0x70 [netjet] [ 44.182989 ] pcidevice_remove+0xa9/0x250(CVE-2021-47468)

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

comedi: vmk80xx: fix bulk-buffer overflow

The driver is using endpoint-sized buffers but must not assume that the tx and rx buffers are of equal size or a malicious device could overflow the slab-allocated receive buffer when doing bulk transfers.(CVE-2021-47474)

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

net: batman-adv: fix error handling

Syzbot reported ODEBUG warning in batadvncmeshfree(). The problem was in wrong error handling in batadvmesh_init().

Before this patch batadvmeshinit() was calling batadvmeshfree() in case of any batadv*init() calls failure. This approach may work well, when there is some kind of indicator, which can tell which parts of batadv are initialized; but there isn't any.

All written above lead to cleaning up uninitialized fields. Even if we hide ODEBUG warning by initializing batpriv->nc.work, syzbot was able to hit GPF in batadvncpurgepaths(), because hash pointer in still NULL. [1]

To fix these bugs we can unwind batadv*init() calls one by one. It is good approach for 2 reasons: 1) It fixes bugs on error handling path 2) It improves the performance, since we won't call unneeded batadv*free() functions.

So, this patch makes all batadv*init() clean up all allocated memory before returning with an error to no call correspoing batadv*free() and open-codes batadvmeshfree() with proper order to avoid touching uninitialized fields.(CVE-2021-47482)

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

regmap: Fix possible double-free in regcacherbtreeexit()

In regcacherbtreeinserttoblock(), when 'present' realloc failed, the 'blk' which is supposed to assign to 'rbnode->block' will be freed, so 'rbnode->block' points a freed memory, in the error handling path of regcacherbtreeinit(), 'rbnode->block' will be freed again in regcacherbtreeexit(), KASAN will report double-free as follows:

BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 Call Trace: slabfreefreelisthook+0x10d/0x240 kfree+0xce/0x390 regcacherbtreeexit+0x15d/0x1a0 regcacherbtreeinit+0x224/0x2c0 regcacheinit+0x88d/0x1310 _regmapinit+0x3151/0x4a80 _devmregmapinit+0x7d/0x100 maderaspiprobe+0x10f/0x333 [maderaspi] spiprobe+0x183/0x210 reallyprobe+0x285/0xc30

To fix this, moving up the assignment of rbnode->block to immediately after the reallocation has succeeded so that the data structure stays valid even if the second reallocation fails.(CVE-2021-47483)

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

IB/qib: Protect from buffer overflow in struct qibusersdma_pkt fields

Overflowing either addrlimit or bytes_togo can allow userspace to trigger a buffer overflow of kernel memory. Check for overflows in all the places doing math on user controlled buffers.(CVE-2021-47485)

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

net/tls: Fix flipped sign in tlserrabort() calls

sk->sk_err appears to expect a positive value, a convention that ktls doesn't always follow and that leads to memory corruption in other code. For instance,

[kworker]
tls_encrypt_done(..., err=<negative error from crypto request>)
  tls_err_abort(.., err)
    sk->sk_err = err;

[task]
splice_from_pipe_feed
  ...
    tls_sw_do_sendpage
      if (sk->sk_err) {
        ret = -sk->sk_err;  // ret is positive

splice_from_pipe_feed (continued)
  ret = actor(...)  // ret is still positive and interpreted as bytes
                    // written, resulting in underflow of buf->len and
                    // sd->len, leading to huge buf->offset and bogus
                    // addresses computed in later calls to actor()

Fix all tlserrabort() callers to pass a negative error code consistently and centralize the error-prone sign flip there, throwing in a warning to catch future misuse and uninlining the function so it really does only warn once.(CVE-2021-47496)

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

ALSA: pcm: oss: Limit the period size to 16MB

Set the practical limit to the period size (the fragment shift in OSS) instead of a full 31bit; a too large value could lead to the exhaust of memory as we allocate temporary buffers of the period size, too.

As of this patch, we set to 16MB limit, which should cover all use cases.(CVE-2021-47509)

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

nfp: Fix memory leak in nfpcppareacacheadd()

In line 800 (#1), nfpcpparea_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak.

We can fix it by freeing the CPP area when the cache is allocated failed (#2).

792 int nfpcppareacacheadd(struct nfpcpp *cpp, sizet size) 793 { 794 struct nfpcppareacache *cache; 795 struct nfpcpp_area *area;

800 area = nfpcppareaalloc(cpp, NFPCPPID(7, NFPCPPACTIONRW, 0), 801 0, size); // #1: allocates and initializes

802 if (!area) 803 return -ENOMEM;

805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free

817 return 0; 818 }(CVE-2021-47516)

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

staging: rtl8192e: Fix use after free in rtl92epci_disconnect()

The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that.(CVE-2021-47571)

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

soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs

In brcmstbpmprobe(), there are two kinds of leak bugs:

(1) we need to add ofnodeput() when foreachmatchingnode() breaks (2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)

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

mmc: mmcspi: fix error handling in mmcspi_probe()

If mmcaddhost() fails, it doesn't need to call mmcremovehost(), or it will cause null-ptr-deref, because of deleting a not added device in mmcremovehost().

To fix this, goto label 'failglueinit', if mmcaddhost() fails, and change the label 'failaddhost' to 'failgpiodrequest'.(CVE-2023-52708)

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

net: USB: Fix wrong-direction WARNING in plusb.c

The syzbot fuzzer detected a bug in the plusb network driver: A zero-length control-OUT transfer was treated as a read instead of a write. In modern kernels this error provokes a WARNING:

usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0 WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411 usbsubmiturb+0x14a7/0x1880 drivers/usb/core/urb.c:411 Modules linked in: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 RIP: 0010:usbsubmiturb+0x14a7/0x1880 drivers/usb/core/urb.c:411 ... Call Trace: <TASK> usbstartwaiturb+0x101/0x4b0 drivers/usb/core/message.c:58 usbinternalcontrolmsg drivers/usb/core/message.c:102 [inline] usbcontrolmsg+0x320/0x4a0 drivers/usb/core/message.c:153 _usbnetreadcmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010 usbnetreadcmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 plvendorreq drivers/net/usb/plusb.c:60 [inline] plsetQuickLinkfeatures drivers/net/usb/plusb.c:75 [inline] plreset+0x2f/0xf0 drivers/net/usb/plusb.c:85 usbnetopen+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 _devopen+0x297/0x4d0 net/core/dev.c:1417 _devchangeflags+0x587/0x750 net/core/dev.c:8530 devchangeflags+0x97/0x170 net/core/dev.c:8602 devinetioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inetioctl+0x33f/0x380 net/ipv4/afinet.c:979 sockdoioctl+0xcc/0x230 net/socket.c:1169 sockioctl+0x1f8/0x680 net/socket.c:1286 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:870 [inline] _sesysioctl fs/ioctl.c:856 [inline] _x64sysioctl+0x197/0x210 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x39/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

The fix is to call usbnetwritecmd() instead of usbnetreadcmd() and remove the USBDIRIN flag.(CVE-2023-52742)

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

IB/hfi1: Restore allocated resources on failed copyout

Fix a resource leak if an error occurs.(CVE-2023-52747)

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

media: gspca: cpia1: shift-out-of-bounds in set_flicker

Syzkaller reported the following issue: UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27 shift exponent 245 is too large for 32-bit type 'int'

When the value of the variable "sd->params.exposure.gain" exceeds the number of bits in an integer, a shift-out-of-bounds error is reported. It is triggered because the variable "currentexp" cannot be left-shifted by more than the number of bits in an integer. In order to avoid invalid range during left-shift, the conditional expression is added.(CVE-2023-52764)

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

fs/jfs: Add check for negative db_l2nbperpage

l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative.

In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent.

Syzbot reported this bug:

UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative(CVE-2023-52810)

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

locking/ww_mutex/test: Fix potential workqueue corruption

In some cases running with the test-wwmutex code, I was seeing odd behavior where sometimes it seemed flushworkqueue was returning before all the work threads were finished.

Often this would cause strange crashes as the mutexes would be freed while they were being used.

Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them.

Unfortunately the workqueue workstruct node is in the stress struct. Which means the workstruct is freed before the work thread returns and while flush_workqueue is waiting.

It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely.

So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns.(CVE-2023-52836)

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:

clk: mediatek: clk-mt2701: Add check for mtkallocclk_data

Add the check for the return value of mtkallocclk_data() in order to avoid NULL pointer dereference.(CVE-2023-52875)

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

tty: ngsm: require CAPNETADMIN to attach NGSM0710 ldisc

Any unprivileged user can attach NGSM0710 ldisc, but it requires CAPNET_ADMIN to create a GSM network anyway.

Require initial namespace CAPNETADMIN to do that.(CVE-2023-52880)

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

net/mlx5e: Prevent deadlock while disabling aRFS

When disabling aRFS under the priv->state_lock, any scheduled aRFS works are canceled using the cancel_work_sync function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the state_lock which is already acquired.

The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules.

Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled.

Kernel log:

====================================================== WARNING: possible circular locking dependency detected

6.7.0-rc4netnextmlx55483eb2 #1 Tainted: G I

ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((workcompletion)(&rule->arfswork)){+.+.}-{0:0}, at: _flushwork+0x74/0x4e0

but task is already holding lock: ffff8884a1808cc0 (&priv->statelock){+.+.}-{3:3}, at: mlx5eethtoolsetchannels+0x53/0x200 [mlx5_core]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&priv->statelock){+.+.}-{3:3}: _mutexlock+0x80/0xc90 arfshandlework+0x4b/0x3b0 [mlx5core] processonework+0x1dc/0x4a0 workerthread+0x1bf/0x3c0 kthread+0xd7/0x100 retfromfork+0x2d/0x50 retfromforkasm+0x11/0x20

-> #0 ((workcompletion)(&rule->arfswork)){+.+.}-{0:0}: _lockacquire+0x17b4/0x2c80 lockacquire+0xd0/0x2b0 _flushwork+0x7a/0x4e0 _cancelworktimer+0x131/0x1c0 arfsdelrules+0x143/0x1e0 [mlx5core] mlx5earfsdisable+0x1b/0x30 [mlx5core] mlx5eethtoolsetchannels+0xcb/0x200 [mlx5core] ethnlsetchannels+0x28f/0x3b0 ethnldefaultsetdoit+0xec/0x240 genlfamilyrcvmsgdoit+0xd0/0x120 genlrcvmsg+0x188/0x2c0 netlinkrcvskb+0x54/0x100 genlrcv+0x24/0x40 netlinkunicast+0x1a1/0x270 netlinksendmsg+0x214/0x460 _socksendmsg+0x38/0x60 _syssendto+0x113/0x170 _x64syssendto+0x20/0x30 dosyscall64+0x40/0xe0 entrySYSCALL64after_hwframe+0x46/0x4e

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(&priv->statelock); lock((workcompletion)(&rule->arfswork)); lock(&priv->statelock); lock((workcompletion)(&rule->arfswork));

* DEADLOCK *

3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cblock){++++}-{3:3}, at: genlrcv+0x15/0x40 #1: ffffffff82e94c88 (rtnlmutex){+.+.}-{3:3}, at: ethnldefaultsetdoit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->statelock){+.+.}-{3:3}, at: mlx5eethtoolsetchannels+0x53/0x200 [mlx5_core]

stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4netnextmlx55483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x60/0xa0 checknoncircular+0x144/0x160 _lockacquire+0x17b4/0x2c80 lockacquire+0xd0/0x2b0 ? _flushwork+0x74/0x4e0 ? savetrace+0x3e/0x360 ? _flushwork+0x74/0x4e0 _flushwork+0x7a/0x4e0 ? _flushwork+0x74/0x4e0 ? _lockacquire+0xa78/0x2c80 ? lockacquire+0xd0/0x2b0 ? markheldlocks+0x49/0x70 _cancelworktimer+0x131/0x1c0 ? markheldlocks+0x49/0x70 arfsdelrules+0x143/0x1e0 [mlx5core] mlx5earfsdisable+0x1b/0x30 [mlx5core] mlx5eethtoolsetchannels+0xcb/0x200 [mlx5core] ethnlsetchannels+0x28f/0x3b0 ethnldefaultsetdoit+0xec/0x240 genlfamilyrcvmsgdoit+0xd0/0x120 genlrcvmsg+0x188/0x2c0 ? ethn ---truncated---(CVE-2024-27014)

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

netfilter: nftables: Fix potential data-race in _nftobjtype_get()

nftunregisterobj() can concurrent with _nftobjtypeget(), and there is not any protection when iterate over nftablesobjects list in _nftobjtypeget(). Therefore, there is potential data-race of nftablesobjects list entry.

Use listforeachentryrcu() to iterate over nftablesobjects list in _nftobjtypeget(), and use rcureadlock() in the caller nftobjtype_get() to protect the entire type query process.(CVE-2024-27019)

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

phonet/pep: fix racy skbqueueempty() use

The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)

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

soc: fsl: qbman: Use raw spinlock for cgr_lock

smpcallfunction always runs its callback in hard IRQ context, even on PREEMPTRT, where spinlocks can sleep. So we need to use a raw spinlock for cgrlock to ensure we aren't waiting on a sleeping task.

Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smpcallfunctionsingle via qmanupdatecgrsafe every time a link goes up or down.(CVE-2024-35819)

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

ubifs: Set page uptodate in the correct place

Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifswriteend(), which is after we copied the new data into the page.(CVE-2024-35821)

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

wifi: libertas: fix some memleaks in lbsallocatecmd_buffer()

In the for statement of lbsallocatecmdbuffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbsallocatecmdbuffer().(CVE-2024-35828)

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

tcp: properly terminate timers for kernel sockets

We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.

Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.

When TCP sockets are closed, we call inetcskclearxmittimers() to 'stop' the timers.

inetcskclearxmittimers() can be called from any context, including when socket lock is held. This is the reason it uses skstoptimer(), aka del_timer(). This means that ongoing timers might finish much later.

For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.

For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.

This patch adds inetcskclearxmittimerssync() function that using skstoptimersync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.

Also add socknotownedbyme() helper to get LOCKDEP support : inetcskclearxmittimers_sync() must not be called while socket lock is held.

It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)

We probably can remove the checknet() tests from tcpoutofresources() and _tcpclose() in the future.(CVE-2024-35910)

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

btrfs: send: handle path ref underflow in header iterateinoderef()

Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.(CVE-2024-35935)

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

wifi: cfg80211: check A-MSDU format more carefully

If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.(CVE-2024-35937)

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

dyndbg: fix old BUG_ON in >control parser

Fix a BUGON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing prerr and return -EINVAL instead.(CVE-2024-35947)

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

batman-adv: Avoid infinite loop trying to resize local TT

If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet.

But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of

batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)

in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more.

There are other scenarios possible with a similar result. The number of BATADVTTCLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes.

While this should be handled proactively when:

• interface with too low MTU is added
• VLAN is added
• non-purgeable local mac is added
• MTU of an attached interface is reduced
• fragmentation setting gets disabled (which most likely requires dropping attached interfaces)

not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.(CVE-2024-35982)

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

tty: ngsm: fix possible out-of-bounds in gsm0receive()

Assuming the following: - side A configures the ngsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration.

Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAXMRU in gsm0receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru.

All other checks remain as we still need to limit the data according to the user configuration and actual payload size.(CVE-2024-36016)

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

tipc: fix UAF in error path

Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipcbufappend() error path:

BUG: KASAN: slab-use-after-free in kfreeskblist_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034

CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> _dumpstack linux/lib/dumpstack.c:88 dumpstacklvl+0xd9/0x1b0 linux/lib/dumpstack.c:106 printaddressdescription linux/mm/kasan/report.c:377 printreport+0xc4/0x620 linux/mm/kasan/report.c:488 kasanreport+0xda/0x110 linux/mm/kasan/report.c:601 kfreeskblistreason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skbreleasedata+0x5af/0x880 linux/net/core/skbuff.c:1026 skbreleaseall linux/net/core/skbuff.c:1094 _kfreeskb linux/net/core/skbuff.c:1108 kfreeskbreason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfreeskb linux/./include/linux/skbuff.h:1244 tipcbufappend+0x425/0xb50 linux/net/tipc/msg.c:186 tipclinkinput+0x224/0x7c0 linux/net/tipc/link.c:1324 tipclinkrcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipcrcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipcudprecv+0x73b/0x8f0 linux/net/tipc/udpmedia.c:390 udpqueuercvoneskb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udpqueuercvskb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udpunicastrcvskb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 _udp4librcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ipprotocoldeliverrcu+0x30c/0x4e0 linux/net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2e4/0x520 linux/net/ipv4/ipinput.c:233 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iplocaldeliver+0x18e/0x1f0 linux/net/ipv4/ipinput.c:254 dstinput linux/./include/net/dst.h:461 iprcvfinish linux/net/ipv4/ipinput.c:449 NFHOOK linux/./include/linux/netfilter.h:314 NFHOOK linux/./include/linux/netfilter.h:308 iprcv+0x2c5/0x5d0 linux/net/ipv4/ipinput.c:569 _netifreceiveskbonecore+0x199/0x1e0 linux/net/core/dev.c:5534 _netifreceiveskb+0x1f/0x1c0 linux/net/core/dev.c:5648 processbacklog+0x101/0x6b0 linux/net/core/dev.c:5976 _napipoll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napipoll linux/net/core/dev.c:6645 netrxaction+0x95a/0xe90 linux/net/core/dev.c:6781 _dosoftirq+0x21f/0x8e7 linux/kernel/softirq.c:553 dosoftirq linux/kernel/softirq.c:454 dosoftirq+0xb2/0xf0 linux/kernel/softirq.c:441 </IRQ> <TASK> _localbhenableip+0x100/0x120 linux/kernel/softirq.c:381 localbhenable linux/./include/linux/bottomhalf.h:33 rcureadunlockbh linux/./include/linux/rcupdate.h:851 _devqueuexmit+0x871/0x3ee0 linux/net/core/dev.c:4378 devqueuexmit linux/./include/linux/netdevice.h:3169 neighhhoutput linux/./include/net/neighbour.h:526 neighoutput linux/./include/net/neighbour.h:540 ipfinishoutput2+0x169f/0x2550 linux/net/ipv4/ipoutput.c:235 _ipfinishoutput linux/net/ipv4/ipoutput.c:313 _ipfinishoutput+0x49e/0x950 linux/net/ipv4/ipoutput.c:295 ipfinishoutput+0x31/0x310 linux/net/ipv4/ipoutput.c:323 NFHOOKCOND linux/./include/linux/netfilter.h:303 ipoutput+0x13b/0x2a0 linux/net/ipv4/ipoutput.c:433 dstoutput linux/./include/net/dst.h:451 iplocalout linux/net/ipv4/ipoutput.c:129 ipsendskb+0x3e5/0x560 linux/net/ipv4/ipoutput.c:1492 udpsendskb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udpsendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inetsendmsg+0x105/0x140 linux/net/ipv4/afinet.c:850 socksendmsgnosec linux/net/socket.c:730 _socksendmsg linux/net/socket.c:745 _syssendto+0x42c/0x4e0 linux/net/socket.c:2191 _dosyssendto linux/net/socket.c:2203 _sesyssendto linux/net/socket.c:2199 _x64syssendto+0xe0/0x1c0 linux/net/socket.c:2199 dosyscallx64 linux/arch/x86/entry/common.c:52 dosyscall_ ---truncated---(CVE-2024-36886)

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

ipv6: prevent NULL dereference in ip6_output()

According to syzbot, there is a chance that ip6dstidev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here.

syzbot reported:

general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6output+0x231/0x3f0 net/ipv6/ip6output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NFHOOK include/linux/netfilter.h:314 [inline] ip6xmit+0xefe/0x17f0 net/ipv6/ip6output.c:358 sctpv6xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctppackettransmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctppacketsingleton+0x22c/0x320 net/sctp/outqueue.c:783 sctpoutqflushctrl net/sctp/outqueue.c:914 [inline] sctpoutqflush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctpsideeffects net/sctp/smsideeffect.c:1198 [inline] sctpdosm+0x59cc/0x60c0 net/sctp/smsideeffect.c:1169 sctpprimitiveASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 _sctpconnect+0x9cd/0xe30 net/sctp/socket.c:1234 sctpconnect net/sctp/socket.c:4819 [inline] sctpinetconnect+0x149/0x1f0 net/sctp/socket.c:4834 _sysconnectfile net/socket.c:2048 [inline] _sysconnect+0x2df/0x310 net/socket.c:2065 _dosysconnect net/socket.c:2075 [inline] _sesysconnect net/socket.c:2072 [inline] _x64sysconnect+0x7a/0x90 net/socket.c:2072 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f(CVE-2024-36901)

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

tcp: defer shutdown(SENDSHUTDOWN) for TCPSYN_RECV sockets

TCPSYNRECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.

In the following crash [1], syzbot managed to trigger a divide by zero in tcprcvspace_adjust()

A socket makes the following state transitions, without ever calling tcpinittransfer(), meaning tcpinitbuffer_space() is also not called.

     TCP_CLOSE

connect() TCPSYNSENT TCPSYNRECV shutdown() -> tcpshutdown(sk, SENDSHUTDOWN) TCPFINWAIT1

To fix this issue, change tcpshutdown() to not perform a TCPSYNRECV -> TCPFIN_WAIT1 transition, which makes no sense anyway.

When tcprcvstateprocess() later changes socket state from TCPSYNRECV to TCPESTABLISH, then look at sk->skshutdown to finally enter TCPFIN_WAIT1 state, and send a FIN packet from a sane socket state.

This means tcpsendfin() can now be called from BH context, and must use GFP_ATOMIC allocations.

[1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcprcvspaceadjust+0x2df/0x890 net/ipv4/tcpinput.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcprecvmsglocked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcprecvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6recvmsg+0x16a/0x730 net/ipv6/afinet6.c:680 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x109/0x280 net/socket.c:1068 _sysrecvmsg+0x1db/0x470 net/socket.c:2803 sysrecvmsg net/socket.c:2845 [inline] dorecvmmsg+0x474/0xae0 net/socket.c:2939 _sysrecvmmsg net/socket.c:3018 [inline] _dosysrecvmmsg net/socket.c:3041 [inline] _sesysrecvmmsg net/socket.c:3034 [inline] _x64sysrecvmmsg+0x199/0x250 net/socket.c:3034 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)

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

scsi: bnx2fc: Remove spinlockbh while releasing resources after upload

The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required.

This will suppress following BUG_ON():

[ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x8664 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fcrporteq fcrportwork [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] _iommudmafree+0x96/0x100 [ 450.000139] bnx2fcfreesessionresc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fcuploadsession+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fcrporteventhandler+0x9f/0x240 [bnx2fc] [ 450.018136] fcrportwork+0x103/0x5b0 [libfc] [ 450.023103] processonework+0x1e8/0x3c0 [ 450.027581] workerthread+0x50/0x3b0 [ 450.031669] ? rescuerthread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? setkthreadstruct+0x40/0x40 [ 450.044411] retfromfork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfslayoutnfsv41files rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver dmservicetime qedf qed crc8 bnx2fc libfcoe libfc scsitransportfc intelraplmsr intelraplcommon x86pkgtempthermal intelpowerclamp dcdbas rapl intelcstate inteluncore meime pcspkr mei ipmissif lpcich ipmisi fuse zram ext4 mbcache jbd2 loop nfsv3 nfsacl nfs lockd grace fscache netfs irdma ice sdmod t10pi sg ibuverbs ibcore 8021q garp mrp stp llc mgag200 i2calgobit drmkmshelper syscopyarea sysfillrect sysimgblt mxmwmi fbsysfops cec crct10difpclmul ahci crc32pclmul bnx2x drm ghashclmulniintel libahci rfkill i40e libata megaraidsas mdio wmi sunrpc lrw dmcrypt dmroundrobin dmmultipath dmsnapshot dmbufio dmmirror dmregionhash dmlog dmzero dmmod linear raid10 raid456 asyncraid6recov asyncmemcpy asyncpq asyncxor asynctx raid6pq libcrc32c crc32cintel raid1 raid0 iscsiibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsibootsysfs iscsitcp libiscsitcp libiscsi scsitransportiscsi edd ipmidevintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---(CVE-2024-36919)

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

bna: ensure the copied buf is NUL terminated

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdupusernul instead of memdup_user.(CVE-2024-36934)

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

scsi: lpfc: Move NPIV's transport unregistration to after resource clean up

There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric.

Currently fcremovehost(), which calls devlosstmo for all DIDs including the fabric DID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch.

Fix by moving the fcremovehost() and scsiremovehost() calls after DA_ID and LOGO are sent.(CVE-2024-36952)

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

drm/vmwgfx: Fix invalid reads in fence signaled events

Correctly set the length of the drm_event to the size of the structure that's actually used.

The length of the drmevent was set to the parent structure instead of to the drmvmweventfence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.(CVE-2024-36960)