The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: cdc_eem: fix tx fixup skb leak

when usbnet transmit a skb, eem fixup it in eemtxfixup(), if skbcopyexpand() failed, it return NULL, usbnetstartxmit() will have no chance to free original skb.

fix it by free orginal skb in eemtxfixup() first, then check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)

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

gfs2: Fix use-after-free in gfs2glockshrink_scan

The GLFLRU flag is checked under lrulock in gfs2glockremovefromlru() to remove the glock from the lru list in _gfs2glock_put().

On the shrink scan path, the same flag is cleared under lrulock but because of condreschedlock(&lrulock) in gfs2disposeglock_lru(), progress on the put side can be made without deleting the glock from the lru list.

Keep GLFLRU across the race window opened by condreschedlock(&lrulock) to ensure correct behavior on both sides - clear GLFLRU after listdel under lru_lock.(CVE-2021-47254)

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

netrom: Decrease sock refcount when sock timers expire

Commit 63346650c1a9 ("netrom: switch to sock timer API") switched to use sock timer API. It replaces modtimer() by skresettimer(), and deltimer() by skstoptimer().

Function skresettimer() will increase the refcount of sock if it is called on an inactive timer, hence, in case the timer expires, we need to decrease the refcount ourselves in the handler, otherwise, the sock refcount will be unbalanced and the sock will never be freed.(CVE-2021-47294)

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

memory: fsl_ifc: fix leak of IO mapping on probe failure

On probe error the driver should unmap the IO memory. Smatch reports:

drivers/memory/fslifc.c:298 fslifcctrlprobe() warn: 'fslifcctrl_dev->gregs' not released on lines: 298.(CVE-2021-47315)

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

watchdog: Fix possible use-after-free in wdt_startup()

This module'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-47324)

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

scsi: megaraid_sas: Fix resource leak in case of probe failure

The driver doesn't clean up all the allocated resources properly when scsiaddhost(), megasasstartaen() function fails during the PCI device probe.

Clean up all those resources.(CVE-2021-47329)

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

ipack: ipoctal: fix module reference leak

A reference to the carrier module was taken on every open but was only released once when the final reference to the tty struct was dropped.

Fix this by taking the module reference and initialising the tty driver data when installing the tty.(CVE-2021-47403)

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

usb: dwc2: check return value after calling platformgetresource()

It will cause null-ptr-deref if platformgetresource() returns NULL, we need check the return value.(CVE-2021-47409)

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

i40e: Fix freeing of uninitialized misc IRQ vector

When VSI set up failed in i40eprobe() as part of PF switch set up driver was trying to free misc IRQ vectors in i40eclearinterruptscheme and produced a kernel Oops:

Trying to free already-free IRQ 266 WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 freeirq+0x9a/0x300 Workqueue: events workforcpufn RIP: 0010:freeirq+0x9a/0x300 Call Trace: ? synchronizeirq+0x3a/0xa0 freeirq+0x2e/0x60 i40eclearinterruptscheme+0x53/0x190 [i40e] i40eprobe.part.108+0x134b/0x1a40 [i40e] ? kmemcachealloc+0x158/0x1c0 ? acpiutupdaterefcount.part.1+0x8e/0x345 ? acpiutupdateobjectreference+0x15e/0x1e2 ? strstr+0x21/0x70 ? irqgetirqdata+0xa/0x20 ? mpcheckpinattr+0x13/0xc0 ? irqgetirqdata+0xa/0x20 ? mpmappintoirq+0xd3/0x2f0 ? acpiregistergsiioapic+0x93/0x170 ? pciconf1read+0xa4/0x100 ? pcibusreadconfigword+0x49/0x70 ? dopcienabledevice+0xcc/0x100 localpciprobe+0x41/0x90 workforcpufn+0x16/0x20 processonework+0x1a7/0x360 workerthread+0x1cf/0x390 ? createworker+0x1a0/0x1a0 kthread+0x112/0x130 ? kthreadflushworkfn+0x10/0x10 retfromfork+0x1f/0x40

The problem is that at that point misc IRQ vectors were not allocated yet and we get a call trace that driver is trying to free already free IRQ vectors.

Add a check in i40eclearinterruptscheme for _I40EMISCIRQREQUESTED PF state before calling i40efreemiscvector. This state is set only if misc IRQ vectors were properly initialized.(CVE-2021-47424)

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

ocfs2: fix data corruption after conversion from inline format

Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in blockwritefull_page()") uncovered a latent bug in ocfs2 conversion from inline inode format to a normal inode format.

The code in ocfs2convertinlinedatatoextents() attempts to zero out the whole cluster allocated for file data by grabbing, zeroing, and dirtying all pages covering this cluster. However these pages are beyond isize, thus writeback code generally ignores these dirty pages and no blocks were ever actually zeroed on the disk.

This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero pages past i_size.") for standard ocfs2 write path, inline conversion path was apparently forgotten; the commit log also has a reasoning why the zeroing actually is not needed.

After commit 6dbf7bb55598, things became worse as writeback code stopped invalidating buffers on pages beyond isize and thus these pages end up with clean PageDirty bit but with buffers attached to these pages being still dirty. So when a file is converted from inline format, then writeback triggers, and then the file is grown so that these pages become valid, the invalid dirtiness state is preserved, markbuffer_dirty() does nothing on these pages (buffers are already dirty) but page is never written back because it is clean. So data written to these pages is lost once pages are reclaimed.

Simple reproducer for the problem is:

xfsio -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \ -c "pwrite 4000 2000" ocfs2file

After unmounting and mounting the fs again, you can observe that end of 'ocfs2_file' has lost its contents.

Fix the problem by not doing the pointless zeroing during conversion from inline format similarly as in the standard write path.

akpm@linux-foundation.org: fix whitespace, per Joseph

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

comedi: ni_usb6501: fix NULL-deref in command paths

The driver uses endpoint-sized USB transfer buffers but had no sanity checks on the sizes. This can lead to zero-size-pointer dereferences or overflowed transfer buffers in ni6501portcommand() and ni6501countercommand() if a (malicious) device has smaller max-packet sizes than expected (or when doing descriptor fuzz testing).

Add the missing sanity checks to probe().(CVE-2021-47476)

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

isofs: Fix out of bound access for corrupted isofs image

When isofs image is suitably corrupted isofsreadinode() can read data beyond the end of buffer. Sanity-check the directory entry length before using it.(CVE-2021-47478)

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

staging: rtl8712: fix use-after-free in rtl8712dlfw

Syzbot reported use-after-free in rtl8712dlfw(). The problem was in race condition between r871xudevremove() ->ndo_open() callback.

It's easy to see from crash log, that driver accesses released firmware in ->ndoopen() callback. It may happen, since driver was releasing firmware _before unregistering netdev. Fix it by moving unregister_netdev() before cleaning up resources.

Call Trace: ... rtl871xopenfw drivers/staging/rtl8712/halinit.c:83 [inline] rtl8712dlfw+0xd95/0xe10 drivers/staging/rtl8712/halinit.c:170 rtl8712halinit drivers/staging/rtl8712/halinit.c:330 [inline] rtl871xhalinit+0xae/0x180 drivers/staging/rtl8712/halinit.c:394 netdevopen+0xe6/0x6c0 drivers/staging/rtl8712/osintfs.c:380 _devopen+0x2bc/0x4d0 net/core/dev.c:1484

Freed by task 1306: ... releasefirmware+0x1b/0x30 drivers/base/firmwareloader/main.c:1053 r871xudevremove+0xcc/0x2c0 drivers/staging/rtl8712/usbintf.c:599 usbunbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458(CVE-2021-47479)

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

iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove

When ACPI type is ACPISMO8500, the data->dreadytrig will not be set, the memory allocated by iiotriggeredbuffer_setup() will not be freed, and cause memory leak as follows:

unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ ....... backtrace: [<0000000041ce75ee>] kmemcachealloctrace+0x16d/0x360 [<000000000aeb17b0>] iiokfifoallocate+0x41/0x130 [kfifobuf] [<000000004b40c1f5>] iiotriggeredbuffersetupext+0x2c/0x210 [industrialiotriggeredbuffer] [<000000004375b15f>] kxcjk1013probe+0x10c3/0x1d81 [kxcjk1013]

Fix it by remove data->dready_trig condition in probe and remove.(CVE-2021-47499)

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

ALSA: pcm: oss: Fix negative period/buffer sizes

The period size calculation in OSS layer may receive a negative value as an error, but the code there assumes only the positive values and handle them with size_t. Due to that, a too big value may be passed to the lower layers.

This patch changes the code to handle with ssize_t and adds the proper error checks appropriately.(CVE-2021-47511)

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

nfc: fix potential NULL pointer deref in nfcgenldumpsesdone

The done() netlink callback nfcgenldumpsesdone() should check if received argument is non-NULL, because its allocation could fail earlier in dumpit() (nfcgenldump_ses()).(CVE-2021-47518)

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

rxrpc: Fix rxrpclocal leak in rxrpclookup_peer()

Need to call rxrpcputlocal() for peer candidate before kfree() as it holds a ref to rxrpc_local.

DH: v2: Changed to abstract the peer freeing code out into a function

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

net/mlx4en: Fix an use-after-free bug in mlx4entryalloc_resources()

In mlx4entryallocresources(), mlx4encopypriv() is called and tmp->txcq will be freed on the error path of mlx4encopypriv(). After that mlx4enallocresources() is called and there is a dereference of &tmp->txcq[t][i] in mlx4enallocresources(), which could lead to a use after free problem on failure of mlx4encopy_priv().

Fix this bug by adding a check of mlx4encopy_priv()

This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.

Builds with CONFIGMLX4EN=m show no new warnings, and our static analyzer no longer warns about this code.(CVE-2021-47541)

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

net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic83xxadd_rings()

In qlcnic83xxaddrings(), the indirect function of ahw->hwops->allocmbxargs will be called to allocate memory for cmd.req.arg, and there is a dereference of it in qlcnic83xxaddrings(), which could lead to a NULL pointer dereference on failure of the indirect function like qlcnic83xxallocmbx_args().

Fix this bug by adding a check of allocmbxargs(), this patch imitates the logic of mbx_cmd()'s failure handling.

This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs.

Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug.

Builds with CONFIG_QLCNIC=m show no new warnings, and our static analyzer no longer warns about this code.(CVE-2021-47542)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47543)

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

tcp: fix page frag corruption on page fault

Steffen reported a TCP stream corruption for HTTP requests served by the apache web-server using a cifs mount-point and memory mapping the relevant file.

The root cause is quite similar to the one addressed by commit 20eb4f29b602 ("net: fix skpagefrag() recursion from memory reclaim"). Here the nested access to the task page frag is caused by a page fault on the (mmapped) user-space memory buffer coming from the cifs file.

The page fault handler performs an smb transaction on a different socket, inside the same process context. Since sk->skallaction for such socket does not prevent the usage for the taskfrag, the nested allocation modify "under the hood" the page frag in use by the outer sendmsg call, corrupting the stream.

The overall relevant stack trace looks like the following:

httpd 78268 [001] 3461630.850950: probe:tcpsendmsglocked: ffffffff91461d91 tcpsendmsglocked+0x1 ffffffff91462b57 tcpsendmsg+0x27 ffffffff9139814e socksendmsg+0x3e ffffffffc06dfe1d smbsendkvec+0x28 [...] ffffffffc06cfaf8 cifsreadpages+0x213 ffffffff90e83c4b readpages+0x6b ffffffff90e83f31 _dopagecachereadahead+0x1c1 ffffffff90e79e98 filemapfault+0x788 ffffffff90eb0458 _dofault+0x38 ffffffff90eb5280 dofault+0x1a0 ffffffff90eb7c84 _handlemmfault+0x4d4 ffffffff90eb8093 handlemmfault+0xc3 ffffffff90c74f6d _dopagefault+0x1ed ffffffff90c75277 dopagefault+0x37 ffffffff9160111e pagefault+0x1e ffffffff9109e7b5 copyin+0x25 ffffffff9109eb40 _copyfromiterfull+0xe0 ffffffff91462370 tcpsendmsglocked+0x5e0 ffffffff91462370 tcpsendmsglocked+0x5e0 ffffffff91462b57 tcpsendmsg+0x27 ffffffff9139815c socksendmsg+0x4c ffffffff913981f7 sockwriteiter+0x97 ffffffff90f2cc56 doiterreadvwritev+0x156 ffffffff90f2dff0 doiterwrite+0x80 ffffffff90f2e1c3 vfswritev+0xa3 ffffffff90f2e27c dowritev+0x5c ffffffff90c042bb dosyscall64+0x5b ffffffff916000ad entrySYSCALL64after_hwframe+0x65

The cifs filesystem rightfully sets skallocations to GFPNOFS, we can avoid the nesting using the sk page frag for allocation lacking the _GFPFS flag. Do not define an additional mm-helper for that, as this is strictly tied to the sk page frag usage.

v1 -> v2: - use a stricted skpagefrag() check instead of reordering the code (Eric)(CVE-2021-47544)

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

net: tulip: de4x5: fix the problem that the array 'lp->phy[8]' may be out of bound

In line 5001, if all id in the array 'lp->phy[8]' is not 0, when the 'for' end, the 'k' is 8.

At this time, the array 'lp->phy[8]' may be out of bound.(CVE-2021-47547)

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

powerpc/powernv: Add a null pointer check in opaleventinit()

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52686)

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

nilfs2: fix underflow in second superblock position calculations

Macro NILFSSB2OFFSET_BYTES, which computes the position of the second superblock, underflows when the argument device size is less than 4096 bytes. Therefore, when using this macro, it is necessary to check in advance that the device size is not less than a lower limit, or at least that underflow does not occur.

The current nilfs2 implementation lacks this check, causing out-of-bound block access when mounting devices smaller than 4096 bytes:

I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)

In addition, when trying to resize the filesystem to a size below 4096 bytes, this underflow occurs in nilfsresizefs(), passing a huge number of segments to nilfssufileresize(), corrupting parameters such as the number of segments in superblocks. This causes excessive loop iterations in nilfssufileresize() during a subsequent resize ioctl, causing semaphore nssegctorsem to block for a long time and hang the writer thread:

INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: <TASK> contextswitch kernel/sched/core.c:5293 [inline] _schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsemdownwriteslowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfstransactionlock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfssegctorthreadconstruct fs/nilfs2/segment.c:2486 [inline] nilfssegctorthread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:308 </TASK> ... Call Trace: <TASK> foliomarkaccessed+0x51c/0xf00 mm/swap.c:515 _nilfsgetpageblock fs/nilfs2/page.c:42 [inline] nilfsgrabbuffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfsmdtsubmitblock+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfsmdtreadblock+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfsmdtgetblock+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfssufilegetsegmentusageblock fs/nilfs2/sufile.c:92 [inline] nilfssufiletruncaterange fs/nilfs2/sufile.c:679 [inline] nilfssufileresize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfsresizefs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfsioctlresize fs/nilfs2/ioctl.c:1033 [inline] nilfsioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ...

This fixes these issues by inserting appropriate minimum device size checks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)

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

drm/amd/display: Avoid NULL dereference of timing generator

[Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference.(CVE-2023-52753)

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

media: imon: fix access to invalid resource for the second interface

imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver.

This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.(CVE-2023-52754)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52756)

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

s390/dasd: protect device queue against concurrent access

In dasdprofilestart() the amount of requests on the device queue are counted. The access to the device queue is unprotected against concurrent access. With a lot of parallel I/O, especially with alias devices enabled, the device queue can change while dasdprofilestart() is accessing the queue. In the worst case this leads to a kernel panic due to incorrect pointer accesses.

Fix this by taking the device lock before accessing the queue and counting the requests. Additionally the check for a valid profile data pointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)

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

SUNRPC: Fix RPC client cleaned up the freed pipefs dentries

RPC client pipefs dentries cleanup is in separated rpcremovepipedir() workqueue,which takes care about pipefs superblock locking. In some special scenarios, when kernel frees the pipefs sb of the current client and immediately alloctes a new pipefs sb, rpcremovepipedir function would misjudge the existence of pipefs sb which is not the one it used to hold. As a result, the rpcremovepipedir would clean the released freed pipefs dentries.

To fix this issue, rpcremovepipedir should check whether the current pipefs sb is consistent with the original pipefs sb.

This error can be catched by KASAN:

[ 250.497700] BUG: KASAN: slab-use-after-free in dgetparent+0x195/0x200 [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503 [ 250.500549] Workqueue: events rpcfreeclientwork [ 250.501001] Call Trace: [ 250.502880] kasanreport+0xb6/0xf0 [ 250.503209] ? dgetparent+0x195/0x200 [ 250.503561] dgetparent+0x195/0x200 [ 250.503897] ? _pfxrpcclntdirdepopulate+0x10/0x10 [ 250.504384] rpcrmdirdepopulate+0x1b/0x90 [ 250.504781] rpcremoveclientdir+0xf5/0x150 [ 250.505195] rpcfreeclientwork+0xe4/0x230 [ 250.505598] processonework+0x8ee/0x13b0 ... [ 22.039056] Allocated by task 244: [ 22.039390] kasansavestack+0x22/0x50 [ 22.039758] kasansettrack+0x25/0x30 [ 22.040109] _kasanslaballoc+0x59/0x70 [ 22.040487] kmemcachealloclru+0xf0/0x240 [ 22.040889] _dalloc+0x31/0x8e0 [ 22.041207] dalloc+0x44/0x1f0 [ 22.041514] _rpclookupcreateexclusive+0x11c/0x140 [ 22.041987] rpcmkdirpopulate.constprop.0+0x5f/0x110 [ 22.042459] rpccreateclientdir+0x34/0x150 [ 22.042874] rpcsetuppipedirsb+0x102/0x1c0 [ 22.043284] rpcclientregister+0x136/0x4e0 [ 22.043689] rpcnewclient+0x911/0x1020 [ 22.044057] rpccreatexprt+0xcb/0x370 [ 22.044417] rpccreate+0x36b/0x6c0 ... [ 22.049524] Freed by task 0: [ 22.049803] kasansavestack+0x22/0x50 [ 22.050165] kasansettrack+0x25/0x30 [ 22.050520] kasansavefreeinfo+0x2b/0x50 [ 22.050921] _kasanslabfree+0x10e/0x1a0 [ 22.051306] kmemcachefree+0xa5/0x390 [ 22.051667] rcucore+0x62c/0x1930 [ 22.051995] _dosoftirq+0x165/0x52a [ 22.052347] [ 22.052503] Last potentially related work creation: [ 22.052952] kasansavestack+0x22/0x50 [ 22.053313] _kasanrecordauxstack+0x8e/0xa0 [ 22.053739] _callrcucommon.constprop.0+0x6b/0x8b0 [ 22.054209] dentryfree+0xb2/0x140 [ 22.054540] _dentrykill+0x3be/0x540 [ 22.054900] shrinkdentrylist+0x199/0x510 [ 22.055293] shrinkdcacheparent+0x190/0x240 [ 22.055703] doonetree+0x11/0x40 [ 22.056028] shrinkdcacheforumount+0x61/0x140 [ 22.056461] genericshutdownsuper+0x70/0x590 [ 22.056879] killanonsuper+0x3a/0x60 [ 22.057234] rpckill_sb+0x121/0x200(CVE-2023-52803)

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

platform/x86: wmi: Fix opening of char device

Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via file private data"), the miscdevice stores a pointer to itself inside filp->privatedata, which means that privatedata will not be NULL when wmicharopen() is called. This might cause memory corruption should wmicharopen() be unable to find its driver, something which can happen when the associated WMI device is deleted in wmifreedevices().

Fix the problem by using the miscdevice pointer to retrieve the WMI device data associated with a char device using containerof(). This also avoids wmichar_open() picking a wrong WMI device bound to a driver with the same name as the original driver.(CVE-2023-52864)

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

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

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

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

soc: qcom: llcc: Handle a second device without data corruption

Usually there is only one llcc device. But if there were a second, even a failed probe call would modify the global drvdata pointer. So check if drvdata is valid before overwriting it.(CVE-2023-52871)

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

efi/capsule-loader: fix incorrect allocation size

gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit physaddrt:

drivers/firmware/efi/capsule-loader.c: In function 'eficapsuleopen': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'physaddrt' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | capinfo->phys = kzalloc(sizeof(void *), GFPKERNEL); | ^

Use the correct type instead here.(CVE-2024-27413)

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

PCI/PM: Drain runtime-idle callbacks before driver removal

A race condition between the .runtimeidle() callback and the .remove() callback in the rtsxpcr PCI driver leads to a kernel crash due to an unhandled page fault [1].

The problem is that rtsxpciruntimeidle() is not expected to be running after pmruntimegetsync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns.

However, if a .runtimeidle() callback is already running when pmruntimegetsync() is called, the latter will notice that the runtime PM status of the device is RPMACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtimeidle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited).

Thus in general, whoever is providing a .runtimeidle() callback needs to protect it from running in parallel with whatever code runs after pmruntimegetsync(). [Note that .runtimeidle() will not start after pmruntimegetsync() has returned, but it may continue running then if it has started earlier.]

One way to address that race condition is to call pmruntimebarrier() after pmruntimegetsync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtimeidle() callback to complete should it be running at that point. A suitable place for doing that is in pcideviceremove() which calls pmruntimegetsync() before removing the driver, so it may as well call pmruntimebarrier() subsequently, which will prevent the race in question from occurring, not just in the rtsxpcr driver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)

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

wifi: brcmfmac: Fix use-after-free bug in brcmfcfg80211detach

This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233

In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker:

->brcmfusbprobe ->brcmfusbprobecb ->brcmfattach ->brcmfbusstarted ->brcmfcfg80211attach ->wlinitpriv ->brcmfinitescan ->INITWORK(&cfg->escantimeoutwork, brcmfcfg80211escantimeout_worker);

If we disconnect the USB by hotplug, it will call brcmfusbdisconnect to make cleanup. The invoking chain is :

brcmfusbdisconnect ->brcmfusbdisconnectcb ->brcmfdetach ->brcmfcfg80211detach ->kfree(cfg);

While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmfcfg80211escantimeoutworker.

Fix it by deleting the timer and canceling the worker in brcmfcfg80211detach.

arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free

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

erspan: make sure erspanbasehdr is present in skb->head

syzbot reported a problem in ip6erspan_rcv() [1]

Issue is that ip6erspanrcv() (and erspanrcv()) no longer make sure erspanbasehdr is present in skb linear part (skb->head) before getting @ver field from it.

Add the missing pskbmaypull() calls.

v2: Reload iph pointer in erspanrcv() after pskbmay_pull() because skb->head might have changed.

[1]

BUG: KMSAN: uninit-value in pskbmaypullreason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskbmaypull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspanrcv net/ipv6/ip6gre.c:541 [inline] BUG: KMSAN: uninit-value in grercv+0x11f8/0x1930 net/ipv6/ip6gre.c:610 pskbmaypullreason include/linux/skbuff.h:2742 [inline] pskbmaypull include/linux/skbuff.h:2756 [inline] ip6erspanrcv net/ipv6/ip6gre.c:541 [inline] grercv+0x11f8/0x1930 net/ipv6/ip6gre.c:610 ip6protocoldeliverrcu+0x1d4c/0x2ca0 net/ipv6/ip6input.c:438 ip6inputfinish net/ipv6/ip6input.c:483 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6input+0x15d/0x430 net/ipv6/ip6input.c:492 ip6mcinput+0xa7e/0xc80 net/ipv6/ip6input.c:586 dstinput include/net/dst.h:460 [inline] ip6rcvfinish+0x955/0x970 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:314 [inline] ipv6rcv+0xde/0x390 net/ipv6/ip6input.c:310 _netifreceiveskbonecore net/core/dev.c:5538 [inline] _netifreceiveskb+0x1da/0xa00 net/core/dev.c:5652 netifreceiveskbinternal net/core/dev.c:5738 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5798 tunrxbatched+0x3ee/0x980 drivers/net/tun.c:1549 tungetuser+0x5566/0x69e0 drivers/net/tun.c:2002 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2108 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xb63/0x1520 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _x64syswrite+0x93/0xe0 fs/readwrite.c:652 dosyscall64+0xd5/0x1f0 entrySYSCALL64after_hwframe+0x6d/0x75

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x613/0xc50 mm/slub.c:3888 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:577 _allocskb+0x35b/0x7a0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] allocskbwithfrags+0xc8/0xbf0 net/core/skbuff.c:6504 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2795 tunallocskb drivers/net/tun.c:1525 [inline] tungetuser+0x209a/0x69e0 drivers/net/tun.c:1846 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2108 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xb63/0x1520 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 _dosyswrite fs/readwrite.c:655 [inline] _sesyswrite fs/readwrite.c:652 [inline] _x64syswrite+0x93/0xe0 fs/readwrite.c:652 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)

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

netfilter: validate user input for expected length

I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt")

setsockopt() @optlen argument should be taken into account before copying data.

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in doreplace net/ipv4/netfilter/iptables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in doiptsetctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238

CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 _asanmemcpy+0x29/0x70 mm/kasan/shadow.c:105 copyfromsockptroffset include/linux/sockptr.h:49 [inline] copyfromsockptr include/linux/sockptr.h:55 [inline] doreplace net/ipv4/netfilter/iptables.c:1111 [inline] doiptsetctl+0x902/0x3dd0 net/ipv4/netfilter/iptables.c:1627 nfsetsockopt+0x295/0x2c0 net/netfilter/nfsockopt.c:101 dosocksetsockopt+0x3af/0x720 net/socket.c:2311 _syssetsockopt+0x1ae/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfb/0x240 entrySYSCALL64afterhwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 </TASK>

Allocated by task 7238: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:370 [inline] _kasankmalloc+0x98/0xb0 mm/kasan/common.c:387 kasankmalloc include/linux/kasan.h:211 [inline] _dokmallocnode mm/slub.c:4069 [inline] _kmallocnoprof+0x200/0x410 mm/slub.c:4082 kmallocnoprof include/linux/slab.h:664 [inline] _cgroupbpfrunfiltersetsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 dosocksetsockopt+0x6b4/0x720 net/socket.c:2293 _syssetsockopt+0x1ae/0x250 net/socket.c:2334 _dosyssetsockopt net/socket.c:2343 [inline] _sesyssetsockopt net/socket.c:2340 [inline] _x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfb/0x240 entrySYSCALL64after_hwframe+0x72/0x7a

The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated---(CVE-2024-35896)

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

i2c: smbus: fix NULL function pointer dereference

Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in _i2ctransfer.

wsa: dropped the simplification in core-smbus to avoid theoretical regressions

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

rtnetlink: Correct nested IFLAVFVLAN_LIST attribute validation

Each attribute inside a nested IFLAVFVLANLIST is assumed to be a struct iflavfvlaninfo so the size of such attribute needs to be at least of sizeof(struct iflavfvlaninfo) which is 14 bytes. The current size validation in dosetvfinfo is against NLAHDRLEN (4 bytes) which is less than sizeof(struct iflavfvlaninfo) so this validation is not enough and a too small attribute might be cast to a struct iflavfvlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)

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

mmc: sdhci-msm: pervent access to suspended controller

Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.(CVE-2024-36029)

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

net: fix out-of-bounds access in ops_init

netallocgeneric is called by netalloc, which is called without any locking. It reads maxgenptrs, which is changed under pernetops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access.

It is possible that the array is allocated and another thread is registering a new pernet ops, increments maxgenptrs, which is then used to set s.len with a larger than allocated length for the variable array.

Fix it by reading maxgenptrs only once in netallocgeneric. If maxgenptrs is later incremented, it will be caught in netassigngeneric.(CVE-2024-36883)

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

ipv6: fib6rules: avoid possible NULL dereference in fib6rule_action()

syzbot is able to trigger the following crash [1], caused by unsafe ip6dstidev() use.

Indeed ip6dstidev() can return NULL, and must always be checked.

[1]

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:_fib6ruleaction net/ipv6/fib6rules.c:237 [inline] RIP: 0010:fib6ruleaction+0x241/0x7b0 net/ipv6/fib6rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fibruleslookup+0x62c/0xdb0 net/core/fibrules.c:317 fib6rulelookup+0x1fd/0x790 net/ipv6/fib6rules.c:108 ip6routeoutputflagsnoref net/ipv6/route.c:2637 [inline] ip6routeoutputflags+0x38e/0x610 net/ipv6/route.c:2649 ip6routeoutput include/net/ip6route.h:93 [inline] ip6dstlookuptail+0x189/0x11a0 net/ipv6/ip6output.c:1120 ip6dstlookupflow+0xb9/0x180 net/ipv6/ip6output.c:1250 sctpv6getdst+0x792/0x1e20 net/sctp/ipv6.c:326 sctptransportroute+0x12c/0x2e0 net/sctp/transport.c:455 sctpassocaddpeer+0x614/0x15c0 net/sctp/associola.c:662 sctpconnectnewasoc+0x31d/0x6c0 net/sctp/socket.c:1099 _sctpconnect+0x66d/0xe30 net/sctp/socket.c:1197 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-36902)

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

ipv6: Fix potential uninit-value access in _ip6make_skb()

As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in _ipmakeskb()") for IPv4, check FLOWIFLAGKNOWNNH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access.(CVE-2024-36903)

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

block: fix overflow in blkioctldiscard()

There is no check for overflow of 'start + len' in blkioctldiscard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.(CVE-2024-36917)

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

scsi: lpfc: Release hbalock before calling lpfcworkerwake_up()

lpfcworkerwakeup() calls the lpfcworkdone() routine, which takes the hbalock. Thus, lpfcworkerwakeup() should not be called while holding the hbalock to avoid potential deadlock.(CVE-2024-36924)

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

tipc: fix a possible memleak in tipcbufappend

_skblinearize() doesn't free the skb when it fails, so move '*buf = NULL' after _skblinearize(), so that the skb can be freed on the err path.(CVE-2024-36954)

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

fs/9p: only translate RWX permissions for plain 9P2000

Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.(CVE-2024-36964)