The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net/mlx5e: Fix use-after-free of encap entry in neigh update handler

Function mlx5erepneigh_update() wasn't updated to accommodate rtnl lock removal from TC filter update path and properly handle concurrent encap entry insertion/deletion which can lead to following use-after-free:

[23827.464923] ================================================================== [23827.469446] BUG: KASAN: use-after-free in mlx5eencaptake+0x72/0x140 [mlx5core] [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635 [23827.472251] [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5 [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [23827.475639] Workqueue: mlx5e mlx5erepneighupdate [mlx5core] [23827.476731] Call Trace: [23827.477260] dumpstack+0xbb/0x107 [23827.477906] printaddressdescription.constprop.0+0x18/0x140 [23827.478896] ? mlx5eencaptake+0x72/0x140 [mlx5core] [23827.479879] ? mlx5eencaptake+0x72/0x140 [mlx5core] [23827.480905] kasanreport.cold+0x7c/0xd8 [23827.481701] ? mlx5eencaptake+0x72/0x140 [mlx5core] [23827.482744] kasancheckrange+0x145/0x1a0 [23827.493112] mlx5eencaptake+0x72/0x140 [mlx5core] [23827.494054] ? mlx5etctunencapinfoequalgeneric+0x140/0x140 [mlx5core] [23827.495296] mlx5erepneighupdate+0x41e/0x5e0 [mlx5core] [23827.496338] ? mlx5erepneighentryrelease+0xb80/0xb80 [mlx5core] [23827.497486] ? readwordatatime+0xe/0x20 [23827.498250] ? strscpy+0xa0/0x2a0 [23827.498889] processonework+0x8ac/0x14e0 [23827.499638] ? lockdephardirqsonprepare+0x400/0x400 [23827.500537] ? pwqdecnrinflight+0x2c0/0x2c0 [23827.501359] ? rwlockbug.part.0+0x90/0x90 [23827.502116] workerthread+0x53b/0x1220 [23827.502831] ? processonework+0x14e0/0x14e0 [23827.503627] kthread+0x328/0x3f0 [23827.504254] ? rawspinunlockirq+0x24/0x40 [23827.505065] ? kthreadbindmask+0x90/0x90 [23827.505912] retfromfork+0x1f/0x30 [23827.506621] [23827.506987] Allocated by task 28248: [23827.507694] kasansavestack+0x1b/0x40 [23827.508476] _kasankmalloc+0x7c/0x90 [23827.509197] mlx5eattachencap+0xde1/0x1d40 [mlx5core] [23827.510194] mlx5etcaddfdbflow+0x397/0xc40 [mlx5core] [23827.511218] _mlx5eaddfdbflow+0x519/0xb30 [mlx5core] [23827.512234] mlx5econfigureflower+0x191c/0x4870 [mlx5core] [23827.513298] tcsetupcbadd+0x1d5/0x420 [23827.514023] flhwreplacefilter+0x382/0x6a0 [clsflower] [23827.514975] flchange+0x2ceb/0x4a51 [clsflower] [23827.515821] tcnewtfilter+0x89a/0x2070 [23827.516548] rtnetlinkrcvmsg+0x644/0x8c0 [23827.517300] netlinkrcvskb+0x11d/0x340 [23827.518021] netlinkunicast+0x42b/0x700 [23827.518742] netlinksendmsg+0x743/0xc20 [23827.519467] socksendmsg+0xb2/0xe0 [23827.520131] syssendmsg+0x590/0x770 [23827.520851] _syssendmsg+0xd8/0x160 [23827.521552] _syssendmsg+0xb7/0x140 [23827.522238] dosyscall64+0x3a/0x70 [23827.522907] entrySYSCALL64afterhwframe+0x44/0xae [23827.523797] [23827.524163] Freed by task 25948: [23827.524780] kasansavestack+0x1b/0x40 [23827.525488] kasansettrack+0x1c/0x30 [23827.526187] kasansetfreeinfo+0x20/0x30 [23827.526968] _kasanslabfree+0xed/0x130 [23827.527709] slabfreefreelisthook+0xcf/0x1d0 [23827.528528] kmemcachefreebulk+0x33a/0x6e0 [23827.529317] kfreercuwork+0x55f/0xb70 [23827.530024] processonework+0x8ac/0x14e0 [23827.530770] workerthread+0x53b/0x1220 [23827.531480] kthread+0x328/0x3f0 [23827.532114] retfromfork+0x1f/0x30 [23827.532785] [23827.533147] Last potentially related work creation: [23827.534007] kasansavestack+0x1b/0x40 [23827.534710] kasanrecordauxstack+0xab/0xc0 [23827.535492] kvfreecallrcu+0x31/0x7b0 [23827.536206] mlx5etcdel ---truncated---(CVE-2021-47247)

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

RDMA: Verify port when creating flow rule

Validate port value provided by the user and with that remove no longer needed validation by the driver. The missing check in the mlx5_ib driver could cause to the below oops.

Call trace: createflowrule+0x2d4/0xf28 [mlx5ib] mlx5ibcreateflow+0x2d0/0x5b0 [mlx5ib] ibuverbsexcreateflow+0x4cc/0x624 [ibuverbs] ibuverbshandlerUVERBSMETHODINVOKEWRITE+0xd4/0x150 [ibuverbs] ibuverbscmdverbs.isra.7+0xb28/0xc50 [ibuverbs] ibuverbsioctl+0x158/0x1d0 [ibuverbs] dovfsioctl+0xd0/0xaf0 ksysioctl+0x84/0xb4 _arm64sysioctl+0x28/0xc4 el0svccommon.constprop.3+0xa4/0x254 el0svchandler+0x84/0xa0 el0svc+0x10/0x26c Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)

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

mISDN: fix possible use-after-free in HFC_cleanup()

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-47356)

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

net: stmmac: Disable Tx queues when reconfiguring the interface

The Tx queues were not disabled in situations where the driver needed to stop the interface to apply a new configuration. This could result in a kernel panic when doing any of the 3 following actions: * reconfiguring the number of queues (ethtool -L) * reconfiguring the size of the ring buffers (ethtool -G) * installing/removing an XDP program (ip l set dev ethX xdp)

Prevent the panic by making sure netiftxdisable is called when stopping an interface.

Without this patch, the following kernel panic can be observed when doing any of the actions above:

Unable to handle kernel paging request at virtual address ffff80001238d040 [....] Call trace: dwmac4setaddr+0x8/0x10 devhardstartxmit+0xe4/0x1ac schdirectxmit+0xe8/0x39c _devqueuexmit+0x3ec/0xaf0 devqueuexmit+0x14/0x20 [...] [ end trace 0000000000000002 ]---(CVE-2021-47558)

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

ice: Fix crash by keep old cfg when update TCs more than queues

There are problems if allocated queues less than Traffic Classes.

Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config for DCB") already disallow setting less queues than TCs.

Another case is if we first set less queues, and later update more TCs config due to LLDP, icevsicfgtc() will failed but left dirty numtxq/rxq and tc_cfg in vsi, that will cause invalid pointer access.

[ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated. [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)! [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0 [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1 [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021 [ 95.969992] RIP: 0010:devmkmalloc+0xa/0x60 [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200 [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Call Trace: [ 95.971622] icesetuprxring+0x39/0x110 [ice] [ 95.971695] icevsisetuprxrings+0x54/0x90 [ice] [ 95.971774] icevsiopen+0x25/0x120 [ice] [ 95.971843] iceopeninternal+0xb8/0x1f0 [ice] [ 95.971919] iceenavsi+0x4f/0xd0 [ice] [ 95.971987] icedcbenadisvsi.constprop.5+0x29/0x90 [ice] [ 95.972082] icepfdcbcfg+0x29a/0x380 [ice] [ 95.972154] icedcbnlsetets+0x174/0x1b0 [ice] [ 95.972220] dcbnlieeeset+0x89/0x230 [ 95.972279] ? dcbnlieeedel+0x150/0x150 [ 95.972341] dcbdoit+0x124/0x1b0 [ 95.972392] rtnetlinkrcvmsg+0x243/0x2f0 [ 95.972457] ? dcbdoit+0x14d/0x1b0 [ 95.972510] ? kmallocnodetrackcaller+0x1d3/0x280 [ 95.972591] ? rtnlcalcit.isra.31+0x100/0x100 [ 95.972661] netlinkrcvskb+0xcf/0xf0 [ 95.972720] netlinkunicast+0x16d/0x220 [ 95.972781] netlinksendmsg+0x2ba/0x3a0 [ 95.975891] socksendmsg+0x4c/0x50 [ 95.979032] syssendmsg+0x2e4/0x300 [ 95.982147] ? kmemcachealloc+0x13e/0x190 [ 95.985242] ? _wakeupcommonlock+0x79/0x90 [ 95.988338] ? _checkobjectsize+0xac/0x1b0 [ 95.991440] ? _copytouser+0x22/0x30 [ 95.994539] ? moveaddrtouser+0xbb/0xd0 [ 95.997619] ? _syssendmsg+0x53/0x80 [ 96.000664] _syssendmsg+0x53/0x80 [ 96.003747] dosyscall64+0x5b/0x1d0 [ 96.006862] entrySYSCALL64afterhwframe+0x65/0xca

Only update numtxq/rxq when passed check, and restore tccfg if setup queue map failed.(CVE-2022-48652)

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

aio: fix mremap after fork null-deref

Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced a null-deref if mremap is called on an old aio mapping after fork as mm->ioctx_table will be set to NULL.

jmoyer@redhat.com: fix 80 column issue

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

riscv: Check if the code to patch lies in the exit section

Otherwise we fall through to vmalloctopage() which panics since the address does not lie in the vmalloc region.(CVE-2023-52677)

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

ALSA: scarlett2: Add missing error checks to *ctlget()

The _ctl_get() functions which call scarlett2_update_() were not checking the return value. Fix to check the return value and pass to the caller.(CVE-2023-52680)

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:

net: openvswitch: fix possible memory leak in ovsmetercmd_set()

old_meter needs to be free after it is detached regardless of whether the new meter is successfully attached.(CVE-2023-52702)

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:

IB/IPoIB: Fix legacy IPoIB due to wrong number of queues

The cited commit creates child PKEY interfaces over netlink will multiple tx and rx queues, but some devices doesn't support more than 1 tx and 1 rx queues. This causes to a crash when traffic is sent over the PKEY interface due to the parent having a single queue but the child having multiple queues.

This patch fixes the number of queues to 1 for legacy IPoIB at the earliest possible point in time.

BUG: kernel NULL pointer dereference, address: 000000000000036b PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0forupstreammindebug202212121702 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmemcachealloc+0xcb/0x450 Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202 RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00 RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40 R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000 R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000 FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbclone+0x55/0xd0 ip6finishoutput2+0x3fe/0x690 ip6finishoutput+0xfa/0x310 ip6sendskb+0x1e/0x60 udpv6sendskb+0x1e5/0x420 udpv6sendmsg+0xb3c/0xe60 ? ipmcfinishoutput+0x180/0x180 ? _switchtoasm+0x3a/0x60 ? _switchtoasm+0x34/0x60 socksendmsg+0x33/0x40 _syssendto+0x103/0x160 ? copytouser+0x21/0x30 ? kvmclockgetcycles+0xd/0x10 ? ktimegetts64+0x49/0xe0 _x64syssendto+0x25/0x30 dosyscall64+0x3d/0x90 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f9374f1ed14 Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIGRAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14 RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030 RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc </TASK>(CVE-2023-52745)

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

xfrm/compat: prevent potential spectre v1 gadget in xfrmxlate32attr()

int type = nla_type(nla);

if (type > XFRMA_MAX) { return -EOPNOTSUPP; }

@type is then used as an array index and can be used as a Spectre v1 gadget.

if (nlalen(nla) < compatpolicy[type].len) {

arrayindexnospec() can be used to prevent leaking content of kernel memory to malicious users.(CVE-2023-52746)

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:

net/smc: avoid data corruption caused by decline

We found a data corruption issue during testing of SMC-R on Redis applications.

The benchmark has a low probability of reporting a strange error as shown below.

"Error: Protocol error, got "\xe2" as reply type byte"

Finally, we found that the retrieved error data was as follows:

0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C 0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2

It is quite obvious that this is a SMC DECLINE message, which means that the applications received SMC protocol message. We found that this was caused by the following situations:

client server ¦ clc proposal -------------> ¦ clc accept <------------- ¦ clc confirm -------------> wait llc confirm send llc confirm ¦failed llc confirm ¦ x------ (after 2s)timeout wait llc confirm rsp

wait decline

(after 1s) timeout (after 2s) timeout ¦ decline --------------> ¦ decline <--------------

As a result, a decline message was sent in the implementation, and this message was read from TCP by the already-fallback connection.

This patch double the client timeout as 2x of the server value, With this simple change, the Decline messages should never cross or collide (during Confirm link timeout).

This issue requires an immediate solution, since the protocol updates involve a more long-term solution.(CVE-2023-52775)

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

ipvlan: add ipvlanroutev6_outbound() helper

Inspired by syzbot reports using a stack of multiple ipvlan devices.

Reduce stack size needed in ipvlanprocessv6outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlanroutev6outbound() needs 120 bytes on the stack, immediately reclaimed.

Also make sure ipvlanprocessv4_outbound() is not inlined.

We might also have to lower MAXNESTDEV, because only syzbot uses setups with more than four stacked devices.

BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasancheckrange+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] _kasancheckread+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrumentatomicread include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _testbit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumasktestcpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpuonline include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] tracelockacquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lockacquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rculockacquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcureadlock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6polroute+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6polrouteoutput+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pollookupfunc include/net/ip6fib.h:584 [inline] [<ffffffff856f65b5>] fib6rulelookup+0x265/0x620 net/ipv6/fib6rules.c:116 [<ffffffff85618009>] ip6routeoutputflagsnoref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6routeoutputflags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6routeoutput include/net/ip6route.h:100 [inline] [<ffffffff838bd5a3>] ipvlanprocessv6outbound drivers/net/ipvlan/ipvlancore.c:473 [inline] [<ffffffff838bd5a3>] ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:529 [inline] [<ffffffff838bd5a3>] ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] [<ffffffff838bd5a3>] ipvlanqueuexmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlancore.c:677 [<ffffffff838c2909>] ipvlanstartxmit+0x49/0x100 drivers/net/ipvlan/ipvlanmain.c:229 [<ffffffff84d03900>] netdevstartxmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmitone net/core/dev.c:3644 [inline] [<ffffffff84d03900>] devhardstartxmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] _devqueuexmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] devqueuexmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neighhh_output include/net/neighbour.h:529 [inline] [<f ---truncated---(CVE-2023-52796)

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

wifi: ath11k: fix dfs radar event locking

The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11kmacgetarbypdevid() was not marked as a read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.

Compile tested only.(CVE-2023-52798)

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

jfs: fix array-index-out-of-bounds in dbFindLeaf

Currently while searching for dmtreet for sufficient free blocks there is an array out of bounds while getting element in tp->dmstree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied.(CVE-2023-52799)

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

wifi: ath11k: fix htt pktlog locking

The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11kmacgetarbypdevid() was not marked as a read-side critical section.

Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues.

Compile tested only.(CVE-2023-52800)

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:

net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs

The hns3 driver define an array of string to show the coalesce info, but if the kernel adds a new mode or a new state, out-of-bounds access may occur when coalesce info is read via debugfs, this patch fix the problem.(CVE-2023-52807)

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:

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:

xen-netfront: Add missing skbmarkfor_recycle

Notice that skbmarkforrecycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("pagepool: Allow drivers to hint on SKB recycling").

It is believed that fixes tag were missing a call to pagepoolreleasepage() between v5.9 to v5.14, after which is should have used skbmarkforrecycle(). Since v6.6 the call pagepoolreleasepage() were removed (in commit 535b9c61bdef ("net: pagepool: hide pagepoolreleasepage()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-pagepool-remove-pagepoolrelease_page'")).

This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/pagepool: catch pagepool memory leaks").(CVE-2024-27393)

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

Bluetooth: l2cap: fix null-ptr-deref in l2capchantimeout

There is a race condition between l2capchantimeout() and l2capchandel(). When we use l2capchandel() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutexlock() of l2capchan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below:

[ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutexlock+0x68/0xc0 [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7 [ 472.075308] [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.075308] Workqueue: events l2capchantimeout [ 472.075308] Call Trace: [ 472.075308] <TASK> [ 472.075308] dumpstacklvl+0x137/0x1a0 [ 472.075308] printreport+0x101/0x250 [ 472.075308] ? _virtaddrvalid+0x77/0x160 [ 472.075308] ? mutexlock+0x68/0xc0 [ 472.075308] kasanreport+0x139/0x170 [ 472.075308] ? mutexlock+0x68/0xc0 [ 472.075308] kasancheckrange+0x2c3/0x2e0 [ 472.075308] mutexlock+0x68/0xc0 [ 472.075308] l2capchantimeout+0x181/0x300 [ 472.075308] processonework+0x5d2/0xe00 [ 472.075308] workerthread+0xe1d/0x1660 [ 472.075308] ? prcontwork+0x5e0/0x5e0 [ 472.075308] kthread+0x2b7/0x350 [ 472.075308] ? prcontwork+0x5e0/0x5e0 [ 472.075308] ? kthreadblkcg+0xd0/0xd0 [ 472.075308] retfromfork+0x4d/0x80 [ 472.075308] ? kthreadblkcg+0xd0/0xd0 [ 472.075308] retfromforkasm+0x11/0x20 [ 472.075308] </TASK> [ 472.075308] ================================================================== [ 472.094860] Disabling lock debugging due to kernel taint [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 472.096136] #PF: supervisor write access in kernel mode [ 472.096136] #PF: errorcode(0x0002) - not-present page [ 472.096136] PGD 0 P4D 0 [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.096136] Workqueue: events l2capchantimeout [ 472.096136] RIP: 0010:mutexlock+0x88/0xc0 [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88 [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246 [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865 [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78 [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000 [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00 [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000 [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0 [ 472.096136] Call Trace: [ 472.096136] <TASK> [ 472.096136] ? _diebody+0x8d/0xe0 [ 472.096136] ? pagefaultoops+0x6b8/0x9a0 [ 472.096136] ? kernelmodefixuporoops+0x20c/0x2a0 [ 472.096136] ? douseraddrfault+0x1027/0x1340 [ 472.096136] ? _printk+0x7a/0xa0 [ 472.096136] ? mutexlock+0x68/0xc0 [ 472.096136] ? addtaint+0x42/0xd0 [ 472.096136] ? excpagefault+0x6a/0x1b0 [ 472.096136] ? asmexcpagefault+0x26/0x30 [ 472.096136] ? mutexlock+0x75/0xc0 [ 472.096136] ? mutexlock+0x88/0xc0 [ 472.096136] ? mutexlock+0x75/0xc0 [ 472.096136] l2capchan_timeo ---truncated---(CVE-2024-27399)

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:

netfilter: bridge: confirm multicast packets before passing them up the stack

conntrack nfconfirm logic cannot handle cloned skbs referencing the same nfconn entry, which will happen for multicast (broadcast) frames on bridges.

Example: macvlan0 | br0 / \ ethX ethY

ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table.

1. skb passes through bridge and fake-ip (brnetfilter)Prerouting. -> skb->nfct now references a unconfirmed entry
2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface.
3. skb gets passed up the stack.

4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices.

   The clone skb->nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RXHANDLER_PASS.

5. Normal conntrack hooks (in NFINETLOCAL_IN) confirm the orig skb.

The Macvlan broadcast worker and normal confirm path will race.

This race will not happen if step 2 already confirmed a clone. In that case later steps perform skbclone() with skb->nfct already confirmed (in hash table). This works fine.

But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nf_confirm step in postrouting.

Pablo points out that nfconntrackbridge doesn't allow use of stateful nat, so we can safely discard the nf_conn entry and let inet call conntrack again.

This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotage_in' hook.

Work around this problem by explicit confirmation of the entry at LOCAL_IN time, before upper layer has a chance to clone the unconfirmed entry.

The downside is that this disables NAT and conntrack helpers.

Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example:

-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5

For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings.

Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.(CVE-2024-27415)

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

usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group

The DisplayPort driver's sysfs nodes may be present to the userspace before typecaltmodesetdrvdata() completes in dpaltmodeprobe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpdshow or dp->lock in pinassignmentshow, as devgetdrvdata() returns NULL in those cases.

Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI.(CVE-2024-35790)

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:

mlxsw: spectrumacltcam: Fix memory leak during rehash

The rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.

If the migration fails, the code tries to migrate the filters back to the old region. However, the rollback itself can also fail in which case another migration will be erroneously performed. Besides the fact that this ping pong is not a very good idea, it also creates a problem.

Each virtual chunk references two chunks: The currently used one ('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the first holds the chunk we want to migrate filters to and the second holds the chunk we are migrating filters from.

The code currently assumes - but does not verify - that the backup chunk does not exist (NULL) if the currently used chunk does not reference the target region. This assumption breaks when we are trying to rollback a rollback, resulting in the backup chunk being overwritten and leaked [1].

Fix by not rolling back a failed rollback and add a warning to avoid future cases.

[1] WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parmandestroy+0x17/0x20 Modules linked in: CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:parmandestroy+0x17/0x20 [...] Call Trace: <TASK> mlxswspaclatcamregionfini+0x19/0x60 mlxswspacltcamregiondestroy+0x49/0xf0 mlxswspacltcamvregionrehashwork+0x1f1/0x470 processonework+0x151/0x370 workerthread+0x2cb/0x3e0 kthread+0xd0/0x100 retfromfork+0x34/0x50 retfromfork_asm+0x1a/0x30 </TASK>(CVE-2024-35853)

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

mlxsw: spectrumacltcam: Fix possible use-after-free during rehash

The rehash delayed work migrates filters from one region to another according to the number of available credits.

The migrated from region is destroyed at the end of the work if the number of credits is non-negative as the assumption is that this is indicative of migration being complete. This assumption is incorrect as a non-negative number of credits can also be the result of a failed migration.

The destruction of a region that still has filters referencing it can result in a use-after-free [1].

Fix by not destroying the region if migration failed.

[1] BUG: KASAN: slab-use-after-free in mlxswspaclctcamregionentryremove+0x21d/0x230 Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858

CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork Call Trace: <TASK> dumpstacklvl+0xc6/0x120 printreport+0xce/0x670 kasanreport+0xd7/0x110 mlxswspaclctcamregionentryremove+0x21d/0x230 mlxswspaclctcamentrydel+0x2e/0x70 mlxswspaclatcamentrydel+0x81/0x210 mlxswspacltcamvchunkmigrateall+0x3cd/0xb50 mlxswspacltcamvregionrehashwork+0x157/0x1300 processonework+0x8eb/0x19b0 workerthread+0x6c9/0xf70 kthread+0x2c9/0x3b0 retfromfork+0x4d/0x80 retfromfork_asm+0x1a/0x30 </TASK>

Allocated by task 174: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 _kasankmalloc+0x8f/0xa0 _kmalloc+0x19c/0x360 mlxswspacltcamregioncreate+0xdf/0x9c0 mlxswspacltcamvregionrehashwork+0x954/0x1300 processonework+0x8eb/0x19b0 workerthread+0x6c9/0xf70 kthread+0x2c9/0x3b0 retfromfork+0x4d/0x80 retfromforkasm+0x1a/0x30

Freed by task 7: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 poisonslabobject+0x102/0x170 _kasanslabfree+0x14/0x30 kfree+0xc1/0x290 mlxswspacltcamregiondestroy+0x272/0x310 mlxswspacltcamvregionrehashwork+0x731/0x1300 processonework+0x8eb/0x19b0 workerthread+0x6c9/0xf70 kthread+0x2c9/0x3b0 retfromfork+0x4d/0x80 retfromfork_asm+0x1a/0x30(CVE-2024-35854)

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

mlxsw: spectrumacltcam: Fix possible use-after-free during activity update

The rule activity update delayed work periodically traverses the list of configured rules and queries their activity from the device.

As part of this task it accesses the entry pointed by 'ventry->entry', but this entry can be changed concurrently by the rehash delayed work, leading to a use-after-free [1].

Fix by closing the race and perform the activity query under the 'vregion->lock' mutex.

[1] BUG: KASAN: slab-use-after-free in mlxswspacltcamflowerruleactivity_get+0x121/0x140 Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181

CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspaclruleactivityupdatework Call Trace: <TASK> dumpstacklvl+0xc6/0x120 printreport+0xce/0x670 kasanreport+0xd7/0x110 mlxswspacltcamflowerruleactivityget+0x121/0x140 mlxswspaclruleactivityupdatework+0x219/0x400 processonework+0x8eb/0x19b0 workerthread+0x6c9/0xf70 kthread+0x2c9/0x3b0 retfromfork+0x4d/0x80 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 1039: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 _kasankmalloc+0x8f/0xa0 _kmalloc+0x19c/0x360 mlxswspacltcamentrycreate+0x7b/0x1f0 mlxswspacltcamvchunkmigrateall+0x30d/0xb50 mlxswspacltcamvregionrehashwork+0x157/0x1300 processonework+0x8eb/0x19b0 workerthread+0x6c9/0xf70 kthread+0x2c9/0x3b0 retfromfork+0x4d/0x80 retfromforkasm+0x1a/0x30

Freed by task 1039: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 poisonslabobject+0x102/0x170 _kasanslabfree+0x14/0x30 kfree+0xc1/0x290 mlxswspacltcamvchunkmigrateall+0x3d7/0xb50 mlxswspacltcamvregionrehashwork+0x157/0x1300 processonework+0x8eb/0x19b0 workerthread+0x6c9/0xf70 kthread+0x2c9/0x3b0 retfromfork+0x4d/0x80 retfromforkasm+0x1a/0x30(CVE-2024-35855)

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

ipv6: Fix infinite recursion in fib6dumpdone().

syzkaller reported infinite recursive calls of fib6dumpdone() during netlink socket destruction. [1]

From the log, syzkaller sent an AFUNSPEC RTMGETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6dumpfib() failed at kzalloc() due to the fault injection. [0]

12:01:34 executing program 3: r0 = socket$nlroute(0x10, 0x3, 0x0) sendmsg$nlroute(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8)

Here, fib6dumpdone() was set to nlksk(sk)->cb.done, and the next call of inet6dumpfib() set it to nlksk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlinksockdestruct() called nlk_sk(sk)->cb.done().

fib6dumpdone() calls fib6dumpend() and nlksk(sk)->cb.done() if it is still not NULL. fib6dumpend() rewrites nlksk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page.

To avoid the issue, let's set the destructor after kzalloc().

name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:117) shouldfailex (lib/fault-inject.c:52 lib/fault-inject.c:153) shouldfailslab (mm/slub.c:3733) kmalloctrace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6dumpfib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6fib.c:662) rtnldumpall (net/core/rtnetlink.c:4029) netlinkdump (net/netlink/afnetlink.c:2269) netlinkrecvmsg (net/netlink/afnetlink.c:1988) _sysrecvmsg (net/socket.c:1046 net/socket.c:2801) sysrecvmsg (net/socket.c:2846) dorecvmmsg (net/socket.c:2943) _x64sysrecvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)

stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlinksockdestructwork RIP: 0010:fib6dumpdone (net/ipv6/ip6fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> </#DF> <TASK> fib6dumpdone (net/ipv6/ip6fib.c:572 (discriminator 1)) fib6dumpdone (net/ipv6/ip6fib.c:572 (discriminator 1)) ... fib6dumpdone (net/ipv6/ip6fib.c:572 (discriminator 1)) fib6dumpdone (net/ipv6/ip6fib.c:572 (discriminator 1)) netlinksockdestruct (net/netlink/afnetlink.c:401) _skdestruct (net/core/sock.c:2177 (discriminator 2)) skdestruct (net/core/sock.c:2224) _skfree (net/core/sock.c:2235) skfree (net/core/sock.c:2246) processonework (kernel/workqueue.c:3259) workerthread (kernel/workqueue.c:3329 kernel/workqueue. ---truncated---(CVE-2024-35886)

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:

bpf, sockmap: Prevent lock inversion deadlock in map delete elem

syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a mapdeleteelem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep:

   CPU0                    CPU1
   ----                    ----

lock(&htab->buckets[i].lock); localirqdisable(); lock(&host->lock); lock(&htab->buckets[i].lock); <Interrupt> lock(&host->lock);

Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context.

Detect when mapdeleteelem operation is invoked from a context which is not hardirq-unsafe, that is interrupts are disabled, and bail out with an error.

Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today.(CVE-2024-35895)

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:

bpf: Protect against int overflow for stack access size

This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in checkstackrange_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail.

This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7.(CVE-2024-35905)

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

nfc: nci: Fix uninit-value in ncidevup and ncintfpacket

syzbot reported the following uninit-value access issue [1][2]:

ncirxwork() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded.

This patch resolved this issue by checking payload size before calling each message type handler codes.(CVE-2024-35915)

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

usb: typec: ucsi: Limit read size on v1.2

Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.(CVE-2024-35924)

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

block: prevent division by zero in blkrqstat_sum()

The expression dst->nrsamples + src->nrsamples may have zero value on overflow. It is necessary to add a check to avoid division by zero.

Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)

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

Bluetooth: SCO: Fix not validating setsockopt user input

syzbot reported scosocksetsockopt() is copying data without checking user input length.

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 scosock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578(CVE-2024-35967)

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

geneve: fix header validation in geneve[6]xmitskb

syzbot is able to trigger an uninit-value in geneve_xmit() [1]

Problem : While most ip tunnel helpers (like iptunnelgetdsfield()) uses skbprotocol(skb, true), pskbinetmay_pull() is only using skb->protocol.

If anything else than ETHPIPV6 or ETHPIP is found in skb->protocol, pskbinetmay_pull() does nothing at all.

If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected.

Add skbvlaninet_prepare() to perform a complete mac validation.

Use this in geneve for the moment, I suspect we need to adopt this more broadly.

v4 - Jakub reported v3 broke l2tosttlinherit.sh selftest - Only call _vlangetprotocol() for vlan types.

v2,v3 - Addressed Sabrina comments on v1 and v2

[1]

BUG: KMSAN: uninit-value in genevexmitskb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in genevexmit+0x302d/0x5420 drivers/net/geneve.c:1030 genevexmitskb drivers/net/geneve.c:910 [inline] genevexmit+0x302d/0x5420 drivers/net/geneve.c:1030 _netdevstartxmit include/linux/netdevice.h:4903 [inline] netdevstartxmit include/linux/netdevice.h:4917 [inline] xmitone net/core/dev.c:3531 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3547 _devqueuexmit+0x348d/0x52c0 net/core/dev.c:4335 devqueuexmit include/linux/netdevice.h:3091 [inline] packetxmit+0x9c/0x6c0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3081 [inline] packetsendmsg+0x8bb0/0x9ef0 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 _syssendto+0x685/0x830 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2199 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 packetallocskb net/packet/afpacket.c:2930 [inline] packetsnd net/packet/afpacket.c:3024 [inline] packetsendmsg+0x722d/0x9ef0 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x30f/0x380 net/socket.c:745 _syssendto+0x685/0x830 net/socket.c:2191 _dosyssendto net/socket.c:2203 [inline] _sesyssendto net/socket.c:2199 [inline] _x64syssendto+0x125/0x1d0 net/socket.c:2199 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024(CVE-2024-35973)

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

ipv4: check for NULL idev in iprouteuse_hint()

syzbot was able to trigger a NULL deref in fibvalidatesource() in an old tree [1].

It appears the bug exists in latest trees.

All calls to _indevgetrcu() must be checked for a NULL result.

[1] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fibvalidatesource+0xbf/0x15a0 net/ipv4/fibfrontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iprouteusehint+0x410/0x9b0 net/ipv4/route.c:2231 iprcvfinishcore+0x2c4/0x1a30 net/ipv4/ipinput.c:327 iplistrcvfinish net/ipv4/ipinput.c:612 [inline] ipsublistrcv+0x3ed/0xe50 net/ipv4/ipinput.c:638 iplistrcv+0x422/0x470 net/ipv4/ipinput.c:673 _netifreceiveskblistptype net/core/dev.c:5572 [inline] _netifreceiveskblistcore+0x6b1/0x890 net/core/dev.c:5620 _netifreceiveskblist net/core/dev.c:5672 [inline] netifreceiveskblistinternal+0x9f9/0xdc0 net/core/dev.c:5764 netifreceiveskblist+0x55/0x3e0 net/core/dev.c:5816 xdprecvframes net/bpf/testrun.c:257 [inline] xdptestrunbatch net/bpf/testrun.c:335 [inline] bpftestrunxdplive+0x1818/0x1d00 net/bpf/testrun.c:363 bpfprogtestrunxdp+0x81f/0x1170 net/bpf/testrun.c:1376 bpfprogtestrun+0x349/0x3c0 kernel/bpf/syscall.c:3736 _sysbpf+0x45c/0x710 kernel/bpf/syscall.c:5115 _dosysbpf kernel/bpf/syscall.c:5201 [inline] _sesysbpf kernel/bpf/syscall.c:5199 [inline] _x64sysbpf+0x7c/0x90 kernel/bpf/syscall.c:5199(CVE-2024-36008)

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:

net: hns3: fix kernel crash when devlink reload during pf initialization

The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devl_lock during initialization.(CVE-2024-36021)

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:

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:

mptcp: ensure snd_nxt is properly initialized on connect

Christoph reported a splat hinting at a corrupted snd_una:

WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 mptcpcleanuna+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcpworker RIP: 0010:mptcpcleanuna+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> _mptcpcleanunawakeup net/mptcp/protocol.c:1055 [inline] mptcpcleanunawakeup net/mptcp/protocol.c:1062 [inline] _mptcpretrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcpworker+0x434/0x740 net/mptcp/protocol.c:2767 processonework+0x1e0/0x560 kernel/workqueue.c:3254 processscheduledworks kernel/workqueue.c:3335 [inline] workerthread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 retfromfork+0x44/0x50 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:243 </TASK>

When fallback to TCP happens early on a client socket, sndnxt is not yet initialized and any incoming ack will copy such value into snduna. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values.

We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice.

Instead address the issue always initializing sndnxt (and writeseq, for consistency) at connect time.(CVE-2024-36889)

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

gpiolib: cdev: fix uninitialised kfifo

If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace.

Initialise the kfifo in the case where the software debounce is already active.(CVE-2024-36898)

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

gpiolib: cdev: Fix use after free in lineinfochangednotify

The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpiochrdevrelease(), watchedlines is freed by bitmapfree(), but the unregistration of lineinfochangednb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines.

Here is the typical stack when issue happened:

[free] gpiochrdevrelease() --> bitmapfree(cdev->watchedlines) <-- freed --> blockingnotifierchainunregister() --> downwrite(&nh->rwsem) <-- waiting rwsem --> _downwritecommon() --> rwsemdownwriteslowpath() --> schedulepreemptdisabled() --> schedule()

[use] st54spigpiodevrelease() --> gpiofree() --> gpiodfree() --> gpiodfreecommit() --> gpiodlinestatenotify() --> blockingnotifiercallchain() --> downread(&nh->rwsem); <-- held rwsem --> notifiercallchain() --> lineinfochangednotify() --> testbit(xxxx, cdev->watchedlines) <-- use after free

The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway.

To fix the issue, call the bitmapfree() function after the unregistration of lineinfochanged_nb notifier chain.(CVE-2024-36899)

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:

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:

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:

ARM: 9381/1: kasan: clear stale stack poison

We found below OOB crash:

[ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refreshcpuvmstats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwindbacktrace from showstack+0x18/0x1c [ 33.458326] showstack from dumpstacklvl+0x40/0x4c [ 33.459072] dumpstacklvl from printreport+0x158/0x4a4 [ 33.459863] printreport from kasanreport+0x9c/0x148 [ 33.460616] kasanreport from kasancheckrange+0x94/0x1a0 [ 33.461424] kasancheckrange from memset+0x20/0x3c [ 33.462157] memset from refreshcpuvmstats.constprop.0+0xcc/0x2ec [ 33.463064] refreshcpuvmstats.constprop.0 from ticknohzidlestoptick+0x180/0x53c [ 33.464181] ticknohzidlestoptick from doidle+0x264/0x354 [ 33.465029] doidle from cpustartupentry+0x20/0x24 [ 33.465769] cpustartupentry from restinit+0xf0/0xf4 [ 33.466528] restinit from archpostacpisubsysinit+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refreshcpuvmstats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'globalzonediff' [ 33.470729] [112, 276) 'globalnode_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ==================================================================

We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle.

This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.

From cited commit [1] that explain the problem

Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning.

In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned.

If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in _cpususpend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel.

Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console.

To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online.

From cited commit [2]

Extend to check for CONFIGKASANSTACK

[1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIGKASANSTACK")(CVE-2024-36906)

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

blk-iocost: do not WARN if iocg was already offlined

In iocgpaydebt(), warn is triggered if 'activelist' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocgwaitqtimerfn() is run at that time:

WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocgpaydebt+0x14c/0x190 Call trace: iocgpaydebt+0x14c/0x190 iocgkickwaitq+0x438/0x4c0 iocgwaitqtimerfn+0xd8/0x130 _runhrtimer+0x144/0x45c _hrtimerrunqueues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0

The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'activelist' is irrelevant, and 'waitqtimer' is canceled after removing 'activelist' in iocpdfree(), which ensures iocg is freed after iocgwaitqtimerfn() returns.

Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk.(CVE-2024-36908)

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:

net: core: reject skbcopy(expand) for fraglist GSO skbs

SKBGSOFRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skbcopy or skbcopyexpand, in order to prevent a crash on a potential later call to skbgso_segment.(CVE-2024-36929)

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

amd/amdkfd: sync all devices to wait all processes being evicted

If there are more than one device doing reset in parallel, the first device will call kfdsuspendall_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.(CVE-2024-36949)

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

octeontx2-af: avoid off-by-one read from userspace

We try to access count + 1 byte from userspace with memdupuser(buffer, count + 1). However, the userspace only provides buffer of count bytes and only these count bytes are verified to be okay to access. To ensure the copied buffer is NUL terminated, we use memdupuser_nul instead.(CVE-2024-36957)

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)