OESA-2024-1694

The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

mptcp: ensure tx skbs always have the MPTCP ext

Due to signed/unsigned comparison, the expression:

info->size_goal - skb->len > 0

evaluates to true when the size goal is smaller than the skb size. That results in lack of tx cache refill, so that the skb allocated by the core TCP code lacks the required MPTCP skb extensions.

Due to the above, syzbot is able to trigger the following WARN_ON():

WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcpsendmsgfrag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Modules linked in: CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:mptcpsendmsgfrag+0x1362/0x1bc0 net/mptcp/protocol.c:1366 Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9 RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216 RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000 RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003 RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280 R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0 FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: _mptcppushpending+0x1fb/0x6b0 net/mptcp/protocol.c:1547 mptcpreleasecb+0xfe/0x210 net/mptcp/protocol.c:3003 releasesock+0xb4/0x1b0 net/core/sock.c:3206 skstreamwaitmemory+0x604/0xed0 net/core/stream.c:145 mptcpsendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749 inet6sendmsg+0x99/0xe0 net/ipv6/afinet6.c:643 socksendmsgnosec net/socket.c:704 [inline] socksendmsg+0xcf/0x120 net/socket.c:724 sockwriteiter+0x2a0/0x3e0 net/socket.c:1057 callwriteiter include/linux/fs.h:2163 [inline] newsyncwrite+0x40b/0x640 fs/readwrite.c:507 vfswrite+0x7cf/0xae0 fs/readwrite.c:594 ksyswrite+0x1ee/0x250 fs/readwrite.c:647 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x4665f9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9 RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003 RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038 R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000

Fix the issue rewriting the relevant expression to avoid sign-related problems - note: size_goal is always >= 0.

Additionally, ensure that the skb in the tx cache always carries the relevant extension.(CVE-2021-47370)

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

scsi: iscsi: Fix iscsi_task use after free

Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsigetconn()/iscsiputconn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsitask use after free, because the common cleanup code will do a put on the iscsitask.

This reverts the goto and moves the iscsigetconn() to after we've checked if the iscsi_task is valid.(CVE-2021-47427)

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

drm/amdgpu: Fix even more out of bound writes from debugfs

CVE-2021-42327 was fixed by:

commit f23750b5b3d98653b31d4469592935ef6364ad67 Author: Thelford Williams <tdwilliamsiv@gmail.com> Date: Wed Oct 13 16:04:13 2021 -0400

drm/amdgpu: fix out of bounds write

but amdgpudmdebugfs.c contains more of the same issue so fix the remaining ones.

v2: * Add missing fix in dpmaxbpc_write (Harry Wentland)(CVE-2021-47489)

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

tcp: TX zerocopy should not sense pfmemalloc status

We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths.

Indeed, for pages coming from user space or other layers, using pageispfmemalloc() is moot, and possibly could give false positives.

There has been attempts to make pageispfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles.

Note to stable teams :

You need to backport 84ce071e38a6 ("net: introduce _skbfillpagedesc_noacc") as a prereq.

Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because pageispfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index.

Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive.

Backporting to older kernel versions seems not necessary.

[1] BUG: KCSAN: data-race in lruaddfn / tcpbuildfrag

write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: _listadd include/linux/list.h:73 [inline] listadd include/linux/list.h:88 [inline] lruvecaddfolio include/linux/mminline.h:105 [inline] lruaddfn+0x440/0x520 mm/swap.c:228 foliobatchmovelru+0x1e1/0x2a0 mm/swap.c:246 foliobatchaddandmove mm/swap.c:263 [inline] folioaddlru+0xf1/0x140 mm/swap.c:490 filemapaddfolio+0xf8/0x150 mm/filemap.c:948 _filemapgetfolio+0x510/0x6d0 mm/filemap.c:1981 pagecachegetpage+0x26/0x190 mm/folio-compat.c:104 grabcachepagewritebegin+0x2a/0x30 mm/folio-compat.c:116 ext4dawritebegin+0x2dd/0x5f0 fs/ext4/inode.c:2988 genericperformwrite+0x1d4/0x3f0 mm/filemap.c:3738 ext4bufferedwriteiter+0x235/0x3e0 fs/ext4/file.c:270 ext4filewriteiter+0x2e3/0x1210 callwriteiter include/linux/fs.h:2187 [inline] newsyncwrite fs/readwrite.c:491 [inline] vfswrite+0x468/0x760 fs/readwrite.c:578 ksyswrite+0xe8/0x1a0 fs/readwrite.c:631 _dosyswrite fs/readwrite.c:643 [inline] _sesyswrite fs/readwrite.c:640 [inline] _x64syswrite+0x3e/0x50 fs/readwrite.c:640 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: pageispfmemalloc include/linux/mm.h:1740 [inline] _skbfillpagedesc include/linux/skbuff.h:2422 [inline] skbfillpagedesc include/linux/skbuff.h:2443 [inline] tcpbuildfrag+0x613/0xb20 net/ipv4/tcp.c:1018 dotcpsendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcpsendpagelocked net/ipv4/tcp.c:1140 [inline] tcpsendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inetsendpage+0x7f/0xc0 net/ipv4/afinet.c:833 kernelsendpage+0x184/0x300 net/socket.c:3561 socksendpage+0x5a/0x70 net/socket.c:1054 pipetosendpage+0x128/0x160 fs/splice.c:361 splicefrompipefeed fs/splice.c:415 [inline] _splicefrompipe+0x222/0x4d0 fs/splice.c:559 splicefrompipe fs/splice.c:594 [inline] genericsplicesendpage+0x89/0xc0 fs/splice.c:743 dosplicefrom fs/splice.c:764 [inline] directspliceactor+0x80/0xa0 fs/splice.c:931 splicedirecttoactor+0x305/0x620 fs/splice.c:886 dosplicedirect+0xfb/0x180 fs/splice.c:974 dosendfile+0x3bf/0x910 fs/readwrite.c:1249 _dosyssendfile64 fs/readwrite.c:1317 [inline] _sesyssendfile64 fs/readwrite.c:1303 [inline] _x64syssendfile64+0x10c/0x150 fs/readwrite.c:1303 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x63/0xcd

value changed: 0x0000000000000000 -> 0xffffea0004a1d288

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)

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

iouring/afunix: disable sending io_uring over sockets

File reference cycles have caused lots of problems for iouring in the past, and it still doesn't work exactly right and races with unixstreamreadgeneric(). The safest fix would be to completely disallow sending iouring files via sockets via SCMRIGHT, so there are no possible cycles invloving registered files and thus rendering SCM accounting on the io_uring side unnecessary.(CVE-2023-52654)

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

crypto: s390/aes - Fix buffer overread in CTR mode

When processing the last block, the s390 ctr code will always read a whole block, even if there isn't a whole block of data left. Fix this by using the actual length left and copy it into a buffer first for processing.(CVE-2023-52669)

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:

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

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

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

sysv: don't call sbbread() with pointerslock held

syzbot is reporting sleep in atomic context in SysV filesystem [1], for sbbread() is called with rwspinlock held.

A "writelock(&pointerslock) => readlock(&pointerslock) deadlock" bug and a "sbbread() with writelock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.

Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointerslock lock to the callers, but instead introduced a "sbbread() with readlock(&pointerslock)" bug (which made this problem easier to hit).

Al Viro suggested that why not to do like getbranch()/getblock()/ findshared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that getbranch() from with findshared() is called without writelock(&pointers_lock).(CVE-2023-52699)

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

arm64: Restrict CPUBIGENDIAN to GNU as or LLVM IAS 15.x or newer

Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0.

This went unnoticed until commit:

34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")

Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when _cpusetup() initialized CPACR_EL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state.

After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g.

| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : _pistrcmp+0x1c/0x150 | lr : populateproperties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dumpbacktrace+0xec/0x108 | showstack+0x18/0x2c | dumpstacklvl+0x50/0x68 | dumpstack+0x18/0x24 | panic+0x13c/0x340 | el1t64irqhandler+0x0/0x1c | el1abort+0x0/0x5c | el1h64sync+0x64/0x68 | _pistrcmp+0x1c/0x150 | unflattendtnodes+0x1e8/0x2d8 | _unflattendevicetree+0x5c/0x15c | unflattendevicetree+0x38/0x50 | setuparch+0x164/0x1e0 | startkernel+0x64/0x38c | _primary_switched+0xbc/0xc4

Restrict CONFIGCPUBIG_ENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit.(CVE-2023-52750)

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

smb: client: fix use-after-free bug in cifsdebugdataprocshow()

Skip SMB sessions that are being teared down (e.g. @ses->sesstatus == SESEXITING) in cifsdebugdataprocshow() to avoid use-after-free in @ses.

This fixes the following GPF when reading from /proc/fs/cifs/DebugData while mounting and umounting

[ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? dieaddr+0x36/0x90 [ 816.260762] ? excgeneralprotection+0x1b3/0x410 [ 816.261126] ? asmexcgeneralprotection+0x26/0x30 [ 816.261502] ? cifsdebugtcon+0xbd/0x240 [cifs] [ 816.261878] ? cifsdebugtcon+0xab/0x240 [cifs] [ 816.262249] cifsdebugdataprocshow+0x516/0xdb0 [cifs] [ 816.262689] ? seqreaditer+0x379/0x470 [ 816.262995] seqreaditer+0x118/0x470 [ 816.263291] procregreaditer+0x53/0x90 [ 816.263596] ? srsoaliasreturnthunk+0x5/0x7f [ 816.263945] vfsread+0x201/0x350 [ 816.264211] ksysread+0x75/0x100 [ 816.264472] dosyscall64+0x3f/0x90 [ 816.264750] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)

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:

pwm: Fix double shift bug

These enums are passed to set/testbit(). The set/testbit() functions take a bit number instead of a shifted value. Passing a shifted value is a double shift bug like doing BIT(BIT(1)). The double shift bug doesn't cause a problem here because we are only checking 0 and 1 but if the value was 5 or above then it can lead to a buffer overflow.(CVE-2023-52756)

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

gfs2: ignore negated quota changes

When lots of quota changes are made, there may be cases in which an inode's quota information is increased and then decreased, such as when blocks are added to a file, then deleted from it. If the timing is right, function doqc can add pending quota changes to a transaction, then later, another call to doqc can negate those changes, resulting in a net gain of 0. The quotachange information is recorded in the qc buffer (and qd element of the inode as well). The buffer is added to the transaction by the first call to doqc, but a subsequent call changes the value from non-zero back to zero. At that point it's too late to remove the buffer_head from the transaction. Later, when the quota sync code is called, the zero-change qd element is discovered and flagged as an assert warning. If the fs is mounted with errors=panic, the kernel will panic.

This is usually seen when files are truncated and the quota changes are negated by punchhole/truncate which uses gfs2quotahold and gfs2quotaunhold rather than block allocations that use gfs2quotalock and gfs2quota_unlock which automatically do quota sync.

This patch solves the problem by adding a check to qdchecksync such that net-zero quota changes already added to the transaction are no longer deemed necessary to be synced, and skipped.

In this case references are taken for the qd and the slot from do_qc so those need to be put. The normal sequence of events for a normal non-zero quota change is as follows:

gfs2quotachange doqc qdhold slot_hold

Later, when the changes are to be synced:

gfs2quotasync qdfish qdchecksync gets qd ref via lockrefgetnotdead dosync doqc(QCSYNC) qdput lockrefputorlock qdunlock qdput lockrefputorlock

In the net-zero change case, we add a check to qdchecksync so it puts the qd and slot references acquired in gfs2quotachange and skip the unneeded sync.(CVE-2023-52759)

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:

tty: vcc: Add check for kstrdup() in vcc_probe()

Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference.(CVE-2023-52789)

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

vhost-vdpa: fix use after free in vhostvdpaprobe()

The putdevice() calls vhostvdpareleasedev() which calls idasimpleremove() and frees "v". So this call to idasimpleremove() is a use after free and a double free.(CVE-2023-52795)

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:

iio: adc: stm32-adc: harden against NULL pointer deref in stm32adcprobe()

ofmatchdevice() may fail and returns a NULL pointer.

In practice there is no known reasonable way to trigger this, but in case one is added in future, harden the code by adding the check(CVE-2023-52802)

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

drm/amdgpu: Fix potential null pointer derefernce

The amdgpurasget_context may return NULL if device not support ras feature, so add check before using.(CVE-2023-52814)

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

drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga

For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)

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

drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference

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

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

cpu/hotplug: Don't offline the last non-isolated CPU

If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARNON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partitionscheddomainslocked().

cpusethotplugworkfn() rebuildscheddomainslocked() ndoms = generatescheddomains(&doms, &attr); cpumaskand(doms[0], topcpuset.effectivecpus, housekeepingcpumask(HKFLAG_DOMAIN));

Thus results in an empty CPU mask which triggers the warning and then the subsequent crash:

WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 buildscheddomains+0x120c/0x1408 Call trace: buildscheddomains+0x120c/0x1408 partitionscheddomainslocked+0x234/0x880 rebuildscheddomainslocked+0x37c/0x798 rebuildscheddomains+0x30/0x58 cpusethotplugworkfn+0x2a8/0x930

Unable to handle kernel paging request at virtual address fffe80027ab37080 partitionscheddomainslocked+0x318/0x880 rebuildscheddomainslocked+0x37c/0x798

Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU.

Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)

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

wifi: mac80211: don't return unset power in ieee80211gettx_power()

We can get a UBSAN warning if ieee80211gettxpower() returns the INTMIN value mac80211 internally uses for "unset power level".

UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dumpstack+0x74/0x92 ubsanepilogue+0x9/0x50 handleoverflow+0x8d/0xd0 _ubsanhandlemuloverflow+0xe/0x10 nl80211sendiface+0x688/0x6b0 [cfg80211] [...] cfg80211registerwdev+0x78/0xb0 [cfg80211] cfg80211netdevnotifiercall+0x200/0x620 [cfg80211] [...] ieee80211ifadd+0x60e/0x8f0 [mac80211] ieee80211registerhw+0xda5/0x1170 [mac80211]

In this case, simply return an error instead, to indicate that no data is available.(CVE-2023-52832)

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

locking/ww_mutex/test: Fix potential workqueue corruption

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

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

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

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

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

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

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

fbdev: imsttfb: fix a resource leak in probe

I've re-written the error handling but the bug is that if initimstt() fails we need to call iounmap(par->cmapregs).(CVE-2023-52838)

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:

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:

can: dev: canputechoskb(): don't crash kernel if canpriv::echo_skb is accessed out of bounds

If the "struct canpriv::echooskb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error.(CVE-2023-52878)

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

drm/amd/display: Fix memory leak in dmswfini()

After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak:

unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloctrace+0x29d/0x340 [<ffffffffc0ea4a94>] dmdmubswinit+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dmswinit+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpudeviceinit+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpudriverloadkms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpupciprobe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] localpciprobe+0x3e/0x90 [<ffffffff996918a3>] pcideviceprobe+0xc3/0x230 [<ffffffff99805872>] reallyprobe+0xe2/0x480 [<ffffffff99805c98>] _driverprobedevice+0x78/0x160 [<ffffffff99805daf>] driverprobedevice+0x1f/0x90 [<ffffffff9980601e>] _driverattach+0xce/0x1c0 [<ffffffff99803170>] busforeachdev+0x70/0xc0 [<ffffffff99804822>] busadddriver+0x112/0x210 [<ffffffff99807245>] driverregister+0x55/0x100 [<ffffffff990012d1>] doone_initcall+0x41/0x300

Fix this by freeing dmub_srv after destroying it.(CVE-2024-26833)

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

crypto: xilinx - call finalize with bh disabled

When calling cryptofinalizerequest, BH should be disabled to avoid triggering the following calltrace:

------------[ cut here ]------------
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
Modules linked in: cryptodev(O)
CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G           O       6.8.0-rc1-yocto-standard #323
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : crypto_finalize_request+0xa0/0x118
lr : crypto_finalize_request+0x104/0x118
sp : ffffffc085353ce0
x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
Call trace:
 crypto_finalize_request+0xa0/0x118
 crypto_finalize_aead_request+0x18/0x30
 zynqmp_handle_aes_req+0xcc/0x388
 crypto_pump_work+0x168/0x2d8
 kthread_worker_fn+0xfc/0x3a0
 kthread+0x118/0x138
 ret_from_fork+0x10/0x20
irq event stamp: 40
hardirqs last  enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0
hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90
softirqs last  enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0
softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0
---[ end trace 0000000000000000 ]---(CVE-2024-26877)

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

USB: core: Fix deadlock in usbdeauthorizeinterface()

Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interfaceauthorizedstore() function is the only one which acquires a device lock on an ancestor device: It calls usbdeauthorizeinterface(), which locks the interface's parent USB device.

The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, devicedel() waits for all ongoing sysfs attribute callbacks to complete. But usbdeauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished.

The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfsbreakactive_protection() function, which tells sysfs not to wait for the attribute callback.

Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com>(CVE-2024-26934)

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

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

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

Use listforeachentryrcu() to iterate over nftablesexpressions list in _nftexprtypeget(), and use rcureadlock() in the caller nftexprtype_get() to protect the entire type query process.(CVE-2024-27020)

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:

firewire: nosy: ensure user_length is taken into account when fetching packet contents

Ensure that packetbufferget respects the userlength provided. If the length of the head packet exceeds the userlength, packetbufferget will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)

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:

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:

wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes

When moving a station out of a VLAN and deleting the VLAN afterwards, the fastrx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211checkfastrx after the VLAN change.(CVE-2024-35789)

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

md/dm-raid: don't call mdreapsync_thread() directly

Currently mdreapsyncthread() is called from raidmessage() directly without holding 'reconfigmutex', this is definitely unsafe because mdreapsyncthread() can change many fields that is protected by 'reconfig_mutex'.

However, hold 'reconfigmutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozensync_thread() to fix deadlock").

Fix this problem by using stopsyncthread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)

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

usb: udc: remove warning when queue disabled ep

It is possible trigger below warning message from mass storage function,

WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usbepqueue+0x7c/0x104 pc : usbepqueue+0x7c/0x104 lr : fsgmainthread+0x494/0x1b3c

Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable.

As there is no function failure in the driver, in order to avoid effort to fix warning, change WARNONONCE() in usbepqueue() to pr_debug().(CVE-2024-35822)

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

vt: fix unicode buffer corruption when deleting characters

This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.(CVE-2024-35823)

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

mptcp: use OPTIONMPTCPMPJSYNACK in subflowfinish_connect()

subflowfinishconnect() uses four fields (backup, joinid, thmac, none) that may contain garbage unless OPTIONMPTCPMPJSYNACK has been set in mptcpparseoption()(CVE-2024-35840)

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:

x86/mm/pat: fix VM_PAT handling in COW mappings

PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings.

Using followphys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing followphys() and triggering a WARNONONCE() in untrackpfn() and trackpfncopy(), not properly calling freepfn_range().

In freepfnrange(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory.

To fix that, let's update followphys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vmpgoff for COW mappings if we run into that.

We will now properly handle untrackpfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->trackpfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size.

For now, lets keep it simple and let trackpfncopy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios.

Simple reproducer to trigger the WARNONONCE() in untrack_pfn():

<--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h>

int main(void) { struct iouringparams p = {}; int ringfd; sizet size; char *map;

     ring_fd = io_uring_setup(1, &p);
     if (ring_fd < 0) {
             perror("io_uring_setup");
             return 1;
     }
     size = p.sq_off.array + p.sq_entries * sizeof(unsigned);

     /* Map the submission queue ring MAP_PRIVATE */
     map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
                ring_fd, IORING_OFF_SQ_RING);
     if (map == MAP_FAILED) {
             perror("mmap");
             return 1;
     }

     /* We have at least one page. Let's COW it. */
     *map = 0;
     pause();
     return 0;

} <--- C reproducer --->

On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrackpfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmtmisc nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectg [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x8664 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrackpfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrackpfn+0xf4/0x100 [ 301.566618] ? _warn+0x81/0x130 [ 301.566876] ? untrackpfn+0xf4/0x100 [ 3 ---truncated---(CVE-2024-35877)

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

netfilter: nf_tables: reject new basechain after table flag update

When dormant flag is toggled, hooks are disabled in the commit phase by iterating over current chains in table (existing and new).

The following configuration allows for an inconsistent state:

add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; }

which triggers the following warning when trying to unregister chain w which is already unregistered.

[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 _nfunregisternethook+0x21a/0x260 [...] [ 127.322519] Call Trace: [ 127.322521] <TASK> [ 127.322524] ? _warn+0x9f/0x1a0 [ 127.322531] ? _nfunregisternethook+0x21a/0x260 [ 127.322537] ? reportbug+0x1b1/0x1e0 [ 127.322545] ? handlebug+0x3c/0x70 [ 127.322552] ? excinvalidop+0x17/0x40 [ 127.322556] ? asmexcinvalidop+0x1a/0x20 [ 127.322563] ? kasansavefreeinfo+0x3b/0x60 [ 127.322570] ? _nfunregisternethook+0x6a/0x260 [ 127.322577] ? _nfunregisternethook+0x21a/0x260 [ 127.322583] ? _nfunregisternethook+0x6a/0x260 [ 127.322590] ? _nftablesunregisterhook+0x8a/0xe0 [nftables] [ 127.322655] nfttabledisable+0x75/0xf0 [nftables] [ 127.322717] nftablescommit+0x2571/0x2620 nftables

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

selinux: avoid dereference of garbage after mount failure

In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer.

While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)

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:

dma-direct: Leak pages on dmasetdecrypted() failure

On TDX it is possible for the untrusted host to cause setmemoryencrypted() or setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

DMA could free decrypted/shared pages if dmasetdecrypted() fails. This should be a rare case. Just leak the pages in this case instead of freeing them.(CVE-2024-35939)

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

drm/client: Fully protect modes[] with dev->mode_config.mutex

The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.(CVE-2024-35950)

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

btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations

Create subvolume, create snapshot and delete subvolume all use btrfssubvolumereservemetadata() to reserve metadata for the changes done to the parent subvolume's fs tree, which cannot be mediated in the normal way via starttransaction. When quota groups (squota or qgroups) are enabled, this reserves qgroup metadata of type PREALLOC. Once the operation is associated to a transaction, we convert PREALLOC to PERTRANS, which gets cleared in bulk at the end of the transaction.

However, the error paths of these three operations were not implementing this lifecycle correctly. They unconditionally converted the PREALLOC to PERTRANS in a generic cleanup step regardless of errors or whether the operation was fully associated to a transaction or not. This resulted in error paths occasionally converting this rsv to PERTRANS without calling recordrootintrans successfully, which meant that unless that root got recorded in the transaction by some other thread, the end of the transaction would not free that root's PERTRANS, leaking it. Ultimately, this resulted in hitting a WARN in CONFIGBTRFS_DEBUG builds at unmount for the leaked reservation.

The fix is to ensure that every qgroup PREALLOC reservation observes the following properties:

1. any failure before recordrootin_trans is called successfully results in freeing the PREALLOC reservation.
2. after recordrootin_trans, we convert to PERTRANS, and now the transaction owns freeing the reservation.

This patch enforces those properties on the three operations. Without it, generic/269 with squotas enabled at mkfs time would fail in ~5-10 runs on my system. With this patch, it ran successfully 1000 times in a row.(CVE-2024-35956)

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

net: ena: Fix incorrect descriptor free behavior

ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDPREDIRECT or XDPTX instructions

The enafreetxbufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napiconsume_skb() for descriptors belonging to an XDP specific queue.

This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.(CVE-2024-35958)

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

net/mlx5: Properly link new fs rules into the tree

Previously, addrulefg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, createflowhandle tries hard to find and reference already existing identical rules instead of creating new ones.

These two behaviors can result in a situation where createflowhandle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because delswhw_rule, invoked on rule deletion, assumes node->parent is != NULL.

This happened in the wild, due to another bug related to incorrect handling of duplicate pktreformat ids, which lead to the code in createflow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].

This patch changes addrulefg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in createflowhandle.(CVE-2024-35960)

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

Bluetooth: Fix memory leak in hcireqsync_complete()

In 'hcireqsync_complete()', always free the previous sync request state before assigning reference to a new one.(CVE-2024-35978)

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

dmaengine: idxd: Fix oops during rmmod on single-CPU platforms

During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops:

BUG: unable to handle page fault for address: 000000000002a2b8
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 1470e1067 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
RIP: 0010:mutex_lock+0x2e/0x50
...
Call Trace:
<TASK>
__die+0x24/0x70
page_fault_oops+0x82/0x160
do_user_addr_fault+0x65/0x6b0
__pfx___rdmsr_safe_on_cpu+0x10/0x10
exc_page_fault+0x7d/0x170
asm_exc_page_fault+0x26/0x30
mutex_lock+0x2e/0x50
mutex_lock+0x1e/0x50
perf_pmu_migrate_context+0x87/0x1f0
perf_event_cpu_offline+0x76/0x90 [idxd]
cpuhp_invoke_callback+0xa2/0x4f0
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
cpuhp_thread_fun+0x98/0x150
smpboot_thread_fn+0x27/0x260
smpboot_thread_fn+0x1af/0x260
__pfx_smpboot_thread_fn+0x10/0x10
kthread+0x103/0x140
__pfx_kthread+0x10/0x10
ret_from_fork+0x31/0x50
__pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
<TASK>

Fix the issue by preventing the migration of the perf context to an invalid target.(CVE-2024-35989)

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

mm/hugetlb: fix missing hugetlb_lock for resv uncharge

There is a recent report on UFFDIO_COPY over hugetlb:

https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/

350: lockdepassertheld(&hugetlb_lock);

Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlbcgroupunchargefoliorsvd() will update the cgroup pointer, so it requires to be called with the lock held.(CVE-2024-36000)

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

i40e: Do not use WQMEMRECLAIM flag for workqueue

Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in checkflushdependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQMEMRECLAIM flag, and the i40iw one is not.

Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too.

[Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQMEMRECLAIM i40e:i40eservicetask [i40e] is flushing !WQMEMRECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 checkflushdependency+0x10b/0x120 [ +0.000007] Modules linked in: sndseqdummy sndhrtimer sndseq sndtimer sndseqdevice snd soundcore nlsutf8 cifs cifsarc4 nlsucs2utils rdmacm iwcm ibcm cifsmd4 dnsresolver netfs qrtr rfkill sunrpc vfat fat intelraplmsr intelraplcommon irdma inteluncorefrequency inteluncorefrequencycommon ice ipmissif isstifcommon skxedac nfit libnvdimm x86pkgtempthermal intelpowerclamp gnss coretemp ibuverbs rapl intelcstate ibcore iTCOwdt iTCOvendorsupport acpiipmi meime ipmisi inteluncore ioatdma i2ci801 joydev pcspkr mei ipmidevintf lpcich intelpchthermal i2csmbus ipmimsghandler acpipowermeter acpipad xfs libcrc32c ast sdmod drmshmemhelper t10pi drmkmshelper sg ixgbe drm i40e ahci crct10difpclmul libahci crc32pclmul igb crc32cintel libata ghashclmulniintel i2calgobit mdio dca wmi dmmirror dmregionhash dmlog dmmod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-netdev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40eservicetask [i40e] [ +0.000024] RIP: 0010:checkflushdependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000002] ? _warn+0x80/0x130 [ +0.000003] ? checkflushdependency+0x10b/0x120 [ +0.000002] ? reportbug+0x195/0x1a0 [ +0.000005] ? handlebug+0x3c/0x70 [ +0.000003] ? excinvalidop+0x14/0x70 [ +0.000002] ? asmexcinvalidop+0x16/0x20 [ +0.000006] ? checkflushdependency+0x10b/0x120 [ +0.000002] ? checkflushdependency+0x10b/0x120 [ +0.000002] _flushworkqueue+0x126/0x3f0 [ +0.000015] ibcachecleanupone+0x1c/0xe0 [ibcore] [ +0.000056] _ibunregisterdevice+0x6a/0xb0 [ibcore] [ +0.000023] ibunregisterdeviceandput+0x34/0x50 [ibcore] [ +0.000020] i40iwclose+0x4b/0x90 [irdma] [ +0.000022] i40enotifyclientofnetdevclose+0x54/0xc0 [i40e] [ +0.000035] i40eservicetask+0x126/0x190 [i40e] [ +0.000024] processonework+0x174/0x340 [ +0.000003] workerth ---truncated---(CVE-2024-36004)

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

mlxsw: spectrumacltcam: Fix warning during rehash

As previously explained, 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.

When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled.

Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1].

Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases.

[1] WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/coreaclflexkeys.c:407 mlxswafkencode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:mlxswafkencode+0x242/0x2f0 [...] Call Trace: <TASK> mlxswspaclatcamentryadd+0xd9/0x3c0 mlxswspacltcamentrycreate+0x5e/0xa0 mlxswspacltcamvchunkmigrateall+0x109/0x290 mlxswspacltcamvregionrehashwork+0x6c/0x470 processonework+0x151/0x370 workerthread+0x2cb/0x3e0 kthread+0xd0/0x100 retfrom_fork+0x34/0x50 </TASK>(CVE-2024-36007)

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

ppdev: Add an error check in register_device

In registerdevice, the return value of idasimpleget is unchecked, in witch idasimple_get will use an invalid index value.

To address this issue, index should be checked after idasimpleget. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.(CVE-2024-36015)

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

pinctrl: core: delete incorrect free in pinctrl_enable()

The "pctldev" struct is allocated in devmpinctrlregisterandinit(). It's a devm_ managed pointer that is freed by devmpinctrldevrelease(), so freeing it in pinctrlenable() will lead to a double free.

The devmpinctrldev_release() function frees the pindescs and destroys the mutex as well.(CVE-2024-36940)