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

wifi: mac80211: fix mbss changed flags corruption on 32 bit systems

On 32-bit systems, the size of an unsigned long is 4 bytes, while a u64 is 8 bytes. Therefore, when using oreachsetbit(bit, &bits, sizeof(changed) BITSPERBYTE), the code is incorrectly searching for a bit in a 32-bit variable that is expected to be 64 bits in size, leading to incorrect bit finding.

Solution: Ensure that the size of the bits variable is correctly adjusted for each architecture.

Call Trace: ? showregs+0x54/0x58 ? warn+0x6b/0xd4 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? reportbug+0x113/0x150 ? excoverflow+0x30/0x30 ? handlebug+0x27/0x44 ? excinvalidop+0x18/0x50 ? handleexception+0xf6/0xf6 ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? ieee80211meshwork+0xff/0x260 [mac80211] ? cfg80211wiphywork+0x72/0x98 [cfg80211] ? processonework+0xf1/0x1fc ? workerthread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? moddelayedworkon+0x4c/0x4c ? kthreadcompleteandexit+0x14/0x14 ? retfromfork+0x24/0x38 ? kthreadcompleteandexit+0x14/0x14 ? retfromforkasm+0xf/0x14 ? entryINT8032+0xf0/0xf0

[restore no-op path for no changes]

ALSA: seq: oss: Fix races at processing SysEx messages

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

net/smc: initialize closework early to avoid warning

We encountered a warning that closework was canceled before initialization.

WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 flushwork+0x19e/0x1b0 Workqueue: events smclgrterminatework [smc] RIP: 0010:flushwork+0x19e/0x1b0 Call Trace: ? wakeupcommon+0x7a/0x190 ? workbusy+0x80/0x80 cancelworktimer+0xe3/0x160 smcclosecancelwork+0x1a/0x70 [smc] smccloseactiveabort+0x207/0x360 [smc] smclgrterminate.part.38+0xc8/0x180 [smc] processonework+0x19e/0x340 workerthread+0x30/0x370 ? processonework+0x340/0x340 kthread+0x117/0x130 ? kthreadcancelwork+0x50/0x50 retfromfork+0x22/0x30

This is because when smcclosecancelwork is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->closework is flushed before initialization, resulting in WARNON(!work->func).

smclgrterminate | smcconnect{rdma|ism} ------------------------------------------------------------- | smcconncreate | \- smclgrregisterconn for conn in lgr->connsall | \- smcconnkill | \- smccloseactiveabort | \- smcclosecancelwork | \- cancelworksync | \- flushwork | (closework) | | smccloseinit | \- INITWORK(&closework)

So fix this by initializing closework before establishing the connection.

drm/dpmst: Ensure mstprimary pointer is valid in drmdpmsthandleupreq()

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

nvme-rdma: unquiesce adminq before destroy it

Kernel will hang on destroy adminq while we create ctrl failed, such as following calltrace:

PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blkmqfreezequeuewait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blkfreezequeue at ffffffff82a4113a #4 [ff61d23de260fc90] blkcleanupqueue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvmerdmadestroyadminqueue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvmerdmasetupctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvmerdmacreatectrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmfdevwrite at ffffffffc024f362 #9 [ff61d23de260fe38] vfswrite at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIGRAX: 0000000000000001 CS: 0033 SS: 002b

This due to we have quiesced admiq before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blkmqfreezequeuewait() forever. Here try to reuse nvmerdmateardownadminqueue() to fix this issue and simplify the code.

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

net: reenable NETIFFIPV6CSUM offload for BIG TCP packets

The blamed commit disabled hardware offoad of IPv6 packets with extension headers on devices that advertise NETIFFIPV6CSUM, based on the definition of that feature in skbuff.h:

- %NETIFFIPV6CSUM - Driver (device) is only able to checksum plain TCP or UDP packets over IPv6. These are specifically unencapsulated packets of the form IPv6|TCP or IPv6|UDP where the Next Header field in the IPv6 header is either TCP or UDP. IPv6 extension headers are not supported with this feature. This feature cannot be set in features for a device with NETIFFHWCSUM also set. This feature is being DEPRECATED (see below).

The change causes skbwarnbadoffload to fire for BIG TCP packets.

[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skbwarnbadoffload+0xc4/0xe0

[ 496.310297] ? skbwarnbadoffload+0xc4/0xe0 [ 496.310300] skbchecksumhelp+0x129/0x1f0 [ 496.310303] skbcsumhwoffloadhelp+0x150/0x1b0 [ 496.310306] validatexmitskb+0x159/0x270 [ 496.310309] validatexmitskblist+0x41/0x70 [ 496.310312] schdirectxmit+0x5c/0x250 [ 496.310317] qdiscrun+0x388/0x620

BIG TCP introduced an IPV6TLVJUMBO IPv6 extension header to communicate packet length, as this is an IPv6 jumbogram. But, the feature is only enabled on devices that support BIG TCP TSO. The header is only present for PFPACKET taps like tcpdump, and not transmitted by physical devices.

For this specific case of extension headers that are not transmitted, return to the situation before the blamed commit and support hardware offload.

ipv6hashopoptjumbo() tests not only whether this header is present, but also that it is the only extension header before a terminal (L4) header.

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

mm: zswap: properly synchronize freeing resources during CPU hotunplug

In zswapcompress() and zswapdecompress(), the per-CPU acompctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.

If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).

The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.

Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acompctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.

The initialization of acompctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.

Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronizesrcu() cannot be used in CPU hotplug notifiers [2].

Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acompctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.

[1]

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

RDMA/siw: Remove direct link to netdevice

Do not manage a per device direct link to netdevice. Rely on associated ibdevices netdevice management, not doubling the effort locally. A badly managed local link to netdevice was causing a 'KASAN: slab-use-after-free' exception during siwqueryport() call.

bpf: consider that tail calls invalidate packet pointers

bpf: check changespktdata property for extension programs

bpf: track changespktdata property for global functions

eth: bnxt: always recalculate features after XDP clearing, fix null-deref

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

net: fec: handle pagepooldevallocpages error

The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!newpage) but it would still proceed to use the NULL pointer and then crash.

This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.

Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.

This commit handles the allocation error by dropping the current packet.

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

iouring/eventfd: ensure ioeventfdsignal() defers another RCU period

ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioevfd should be deferred another RCU grace period.

Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.

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

topology: Keep the cpumask unchanged when printing cpumap

During fuzz testing, the following warning was discovered:

different return values (15 and 11) from vsnprintf("%pbl ", ...)

test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2

The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:

(1) First, calculate the length of the resulting formatted string.

(2) Allocate a buffer based on the returned length.

(3) Then, perform the actual string formatting.

(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.

If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.

To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.

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

scsi: sg: Fix slab-use-after-free read in sgrelease()

Fix a use-after-free bug in sgrelease(), detected by syzbot with KASAN:

BUG: KASAN: slab-use-after-free in lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5838 mutexunlockslowpath+0xe2/0x750 kernel/locking/mutex.c:912 sgrelease+0x1f4/0x2e0 drivers/scsi/sg.c:407

In sgrelease(), the function krefput(&sfp->fref, sgremovesfp) is called before releasing the openrellock mutex. The krefput() call may decrement the reference count of sfp to zero, triggering its cleanup through sgremovesfp(). This cleanup includes scheduling deferred work via sgremovesfpusercontext(), which ultimately frees sfp.

After krefput(), sgrelease() continues to unlock openrellock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.

Move the krefput(&sfp->fref, sgremovesfp) call after unlocking the openrellock mutex. This ensures:

- No references to sfp or sdp occur after the reference count is decremented.

- Cleanup functions such as sgremovesfp() and sgremovesfpusercontext() can safely execute without impacting the mutex handling in sgrelease().

The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sgrelease().

afpacket: fix vlangetprotocoldgram() vs MSGPEEK

afpacket: fix vlangettci() vs MSGPEEK

gfs2: Truncate address space when flipping GFS2DIFJDATA flag

drm/v3d: Ensure job pointer is set to NULL after job completion

hrtimers: Handle CPU state correctly on hotplug

ila: serialize calls to nfregisternethooks()

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

sctp: sysctl: udpport: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using containerof().

Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctlsock' still needs to be retrieved from 'net' structure.

btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount

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

ksmbd: fix a missing return value check bug

In the smb2sendinterimresp(), if ksmbdallocworkstruct() fails to allocate a node, it returns a NULL pointer to the inwork pointer. This can lead to an illegal memory write of inwork->responsebuf when allocateinterimrspbuf() attempts to perform a kzalloc() on it.

To address this issue, incorporating a check for the return value of ksmbdallocworkstruct() ensures that the function returns immediately upon allocation failure, thereby preventing the aforementioned illegal memory access.

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

sctp: sysctl: cookiehmacalg: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using containerof().

Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use 'data' everywhere 'net->sctp.sctphmacalg' is used.

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

ocfs2: fix slab-use-after-free due to dangling pointer dqipriv

When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quotagetnextquota. Specifically, sbdqinfo(sb, type)->dqipriv is the dangling pointer.

During the remounting process, the pointer dqipriv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOTSUSPENDED flag instead of setting the DQUOTUSAGEENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2getnextid is called and only checks the quota usage flags and not the quota suspended flags.

To fix this, I set dqipriv to null when it is freed after remounting with read-only and put a check for DQUOTSUSPENDED in ocfs2getnextid.

[akpm@linux-foundation.org: coding-style cleanups]

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

sctp: sysctl: authenable: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The 'net' structure can be obtained from the table->data using containerof().

Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctlsock' still needs to be retrieved from 'net' structure.

drm: adv7511: Fix use-after-free in adv7533attachdsi()

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

mtd: rawnand: fix double free in atmelpmecccreateuser()

The "user" pointer was converted from being allocated with kzalloc() to being allocated by devmkzalloc(). Calling kfree(user) will lead to a double free.