In getehtoperationchannelwidth of ieee80211common.c, there is a possible out of bounds read due to an incorrect bounds check. This could lead to remote (proximal/adjacent) information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.

The kernel queue helper zqueuenodepeek() in kernel/queue.c dereferences a node taken from a queue's dataq list, reading the node's flag byte and, for items enqueued via kqueueallocappend/allocprepend, the data pointer of an internally allocated allocnode struct. The implementations of zimplkqueuepeekhead() and zimplkqueuepeektail() performed this read-and-dereference without holding the queue's spinlock, while every other accessor of the same list — including kqueueget(), which unlinks a node and kfree()s its backing allocnode — operates under that lock.

Because peek was unsynchronized, a concurrent kqueueget() on the same queue (on an SMP build, or under preemption/ISR concurrency) can free the node between the moment peek obtains the node pointer and the moment it dereferences it. The peek then reads flag bits and a data pointer out of freed, potentially re-allocated heap memory and returns a stale or dangling pointer to its caller. kfifo and klifo are thin wrappers over kqueue, so this affects buffer queues used throughout the netbuf, Bluetooth, USB, and networking subsystems; the peek operations are also system calls reachable from CONFIGUSERSPACE threads.

The consequences are a use-after-free read that can leak stale heap contents (one pointer word) and, when the returned dangling pointer is subsequently consumed as a live buffer, a dereference that can crash the system or corrupt memory. Exploitation requires winning a small race window with local access (e.g. a userspace process racing kqueuepeek against kqueueget on a shared queue, or two CPUs), so practical impact is bounded and of low severity.

The fix wraps both peek implementations with kspinlock/kspinunlock on the queue lock, making the read-and-dereference atomic with respect to the concurrent unlink-and-free and bringing peek into line with the rest of the queue's locking discipline.

drm/bridge: cdns-dsi: Replace deprecated UNIVERSALDEVPMOPS()

drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

futex: Prevent robust futex exit race some more

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

net: mpls: initialize rtmtos in mplsgetroute()

mplsgetroute() builds the RTMNEWROUTE reply to an RTMGETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (allocskb(NLMSGGOODSIZE, ...)). It sets every field of the header except rtmtos:

r = nlmsgdata(nlh); r->rtmfamily = AFMPLS; r->rtmdstlen = 20; r->rtmsrclen = 0; r->rtmtable = RTTABLEMAIN; r->rtmtype = RTNUNICAST; r->rtmscope = RTSCOPEUNIVERSE; r->rtmprotocol = rt->rtprotocol; r->rtmflags = 0;

struct rtmsg has no padding, so the one uninitialised byte rtmtos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mplsdumproute(), which fills the very same header and does set rtmtos = 0.

Initialize rtmtos to 0, matching mplsdumproute().

Reproduced with KMSAN by adding an MPLS route and issuing a non-RTMFFIBMATCH RTMGETROUTE for its label:

BUG: KMSAN: kernel-infoleak in copytoiter+0x36c/0x33f0 copytoiter+0x36c/0x33f0 skbdatagramiter+0x196/0x12c0 skbcopydatagramiter+0x5b/0x210 netlinkrecvmsg+0x37b/0xef0 ... Uninit was created at: allocskb+0x8ca/0x10e0 mplsgetroute+0x1280/0x3a40 rtnetlinkrcvmsg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized

(byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtmtos)

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

net: sxgbe: free TX rings on RX allocation failure

When RX descriptor ring allocation fails, initdmadescrings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked.

Rearrange error labels to clean up TX rings upon RX failures.

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

wifi: brcmfmac: initialize SDIO data work before cleanup

brcmfsdioprobe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmfsdioremove().

brcmfsdioremove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmfsdioremove(), so the cleanup path always observes a valid work object.

This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run.

A QEMU PoC forced allocorderedworkqueue() to fail at the same point in brcmfsdioprobe(), before INITWORK(&bus->datawork) is reached. The resulting fail path calls brcmfsdioremove(), and DEBUGOBJECTS reports the invalid work drain with brcmfsdioprobe() and brcmfsdioremove() in the stack.

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

wifi: ipw2100: fix potential memory leak in ipw2100pciinitone()

The memory allocated in the ipw2100allocdevice() function is not freed in some of the error paths in ipw2100pciinitone(). Fix that by converting the direct return into a goto to the error path return.

The error path when pcienabledevice() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.

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

wifi: brcmfmac: fix 802.1X-SHA256 call trace warning

Based on wpaauth as 1x256 mode, need to set up "usefwsup" with BRCMFPROFILEFWSUP1X. Or it will happen trace warning when call brcmfcfg80211setpmk().

[ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmfcfg80211setpmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]  <TASK> [ 4481.831205]  nl80211setpmk+0x183/0x250 [cfg80211] [ 4481.831233]  genlfamilyrcvmsgdoit+0xea/0x150 [ 4481.831237]  genlrcvmsg+0x104/0x240 [ 4481.831239]  ? cfg80211probestatus+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genlfamilyrcvmsgdoit+0x150/0x150 [ 4481.831259]  netlinkrcvskb+0x4e/0x100 [ 4481.831261]  genlrcv+0x24/0x40 [ 4481.831262]  netlinkunicast+0x236/0x380 [ 4481.831264]  netlinksendmsg+0x250/0x4b0 [ 4481.831266]  socksendmsg+0x5c/0x70 [ 4481.831269]  syssendmsg+0x236/0x2b0 [ 4481.831271]  ? copymsghdrfromuser+0x6d/0xa0 [ 4481.831272]  syssendmsg+0x86/0xd0 [ 4481.831274]  ? avchasperm+0x8c/0x1a0 [ 4481.831276]  ? preemptcountadd+0x6a/0xa0 [ 4481.831279]  ? sockhasperm+0x82/0xa0 [ 4481.831280]  syssendmsg+0x57/0xa0 [ 4481.831282]  dosyscall64+0x38/0x90 [ 4481.831284]  entrySYSCALL64afterhwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4

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

wifi: mt76: connac: fix possible NULL-pointer deref in mt76connacmcuunibsshetlv()

mt76connacgethephycap routine can theoretically return NULL so check cap pointer before dereferencing it.

drm/i915/gem: Do not leak siblings[] on proto context error

drm/i915: Return NULL on error in activeinstance

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

media: cx23885: add ioremap return check and cleanup

Add a check for the return value of pciioremapbar() in cx23885devsetup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV.

This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

shmem: fix recovery on rename failures

mapletree insertions can fail if we are seriously short on memory; simpleoffsetrename() does not recover well if it runs into that. The same goes for simpleoffsetrenameexchange().

Moreover, shmemwhiteout() expects that if it succeeds, the caller will progress to dmove(), i.e. that shmemrename2() won't fail past the successful call of shmemwhiteout().

Not hard to fix, fortunately - mtreestore() can't fail if the index we are trying to store into is already present in the tree as a singleton.

For simpleoffsetrenameexchange() that's enough - we just need to be careful about the order of operations.

For simpleoffsetrename() solution is to preinsert the target into the tree for newdir; the rest can be done without any potentially failing operations.

That preinsertion has to be done in shmemrename2() rather than in simpleoffsetrename() itself - otherwise we'd need to deal with the possibility of failure after successful shmemwhiteout().

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

timers: Fix NULL function pointer race in timershutdownsync()

There is a race condition between timershutdownsync() and timer expiration that can lead to hitting a WARNON in expiretimers().

The issue occurs when timershutdownsync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:

CPU0 CPU1 <SOFTIRQ> locktimerbase() expiretimers() base->runningtimer = timer; unlocktimerbase() [calltimerfn enter] modtimer() ... timershutdownsync() locktimerbase() // For now, will not detach the timer but only clear its function to NULL if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimerbase() [calltimerfn exit] locktimerbase() base->runningtimer = NULL; unlocktimerbase() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expiretimers() WARNONONCE(!fn) // hit ... locktimerbase() // Now timer will detach if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimerbase()

The problem is that timershutdownsync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARNONONCE(!fn) check in expiretimers().

Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.

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

crypto: afalg - zero initialize memory allocated via sockkmalloc

Several crypto user API contexts and requests allocated with sockkmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future.

The ACVP patches also contain two user-space interface files: algifkpp.c and algifakcipher.c. These too rely on proper initialization of their context structures.

A particular issue has been observed with the newly added 'inflight' variable introduced in afalgctx by commit:

67b164a871af ("crypto: afalg - Disallow multiple in-flight AIO requests")

Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, afalgallocareq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:

https://github.com/gregkh/linux/blame/master/crypto/afalg.c#L1209

The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sockkmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.

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

OPP: fix devpmoppfindbw() when bandwidth table not initialized

If a driver calls devpmoppfindbwceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : readbw+0x8/0x10 lr : opptablefindkey+0x9c/0x174 ... Call trace: readbw+0x8/0x10 (P) opptablefindkey+0x9c/0x174 (L) findkey+0x98/0x168 devpmoppfindbwceil+0x50/0x88 ...

In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with readbw().

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

powerpc/xive/spapr: correct bitmap allocation size

kasan detects access beyond the end of the xibm->bitmap allocation:

BUG: KASAN: slab-out-of-bounds in findfirstzerobit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1

CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dumpstacklvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] printreport+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasanreport+0x110/0x354 [c00000001d98f950] [c000000000692324] asanload8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] findfirstzerobit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xivespaprgetipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xivesetupcpuipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeriessmpprobe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smppreparecpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernelinitfreeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernelinit+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] retfromkernelthread+0x5c/0x64

Allocated by task 0: kasansavestack+0x34/0x70 kasankmalloc+0xb4/0xf0 kmalloc+0x268/0x540 xivespaprinit+0x4d0/0x77c pseriesinitirq+0x40/0x27c initIRQ+0x44/0x84 startkernel+0x2a4/0x538 startherecommon+0x1c/0x20

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

The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc

This happens because the allocation uses the wrong unit (bits) when it should pass (BITSTOLONGS(count) sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses.

Use bitmapzalloc() to allocate and initialize the irq bitmap, paired with bitmapfree() for consistency.

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

powerpc/xics: fix refcount leak in icpopalinit()

The offindcompatiblenode() function returns a node pointer with refcount incremented, use ofnodeput() on it when done.

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

HID: hid-thrustmaster: Fix warning in thrustmasterprobe by adding endpoint check

syzbot has found a type mismatch between a USB pipe and the transfer endpoint, which is triggered by the hid-thrustmaster driver[1]. There is a number of similar, already fixed issues [2]. In this case as in others, implementing check for endpoint type fixes the issue.

[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470 [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622

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

bpf: Fix softlockup in arenamapfree on 64k page kernel

On an aarch64 kernel with CONFIGPAGESIZE64KB=y, arenahtab tests cause a segmentation fault and soft lockup. The same failure is not observed with 4k pages on aarch64.

It turns out arenamapfree() is calling applytoexistingpagerange() with the address returned by bpfarenagetkernvmstart(). If this address is not page-aligned the code ends up calling applytopterange() with that unaligned address causing soft lockup.

Fix it by round up GUARDSZ to PAGESIZE << 1 so that the division by 2 in bpfarenagetkernvmstart() returns a page-aligned value.

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

tracing/histograms: Fix memory leak problem

This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.

As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parsevardefs() if there is a problem allocating > vardefs.expr, the earlier vardefs.name is freed. > This free is duplicated by freevardefs() which frees > the rest of the list.

However, if there is a problem allocating N-th vardefs.expr: + in parsevardefs(), the freed 'earlier vardefs.name' is actually the N-th vardefs.name; + then in freevardefs(), the names from 0th to (N-1)-th are freed;

IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- vardefs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+-----------

These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th vardefs.name" is not freed.

If enable CONFIGDEBUGKMEMLEAK and inject a fault at where the N-th vardefs.expr allocated, then execute on shell like: $ echo 'hist:key=callsite:val=$v1,$v2:v1=bytesreq,v2=bytesalloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger

Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] eventhisttriggerparse+0x206f/0x20e0 [<00000000ae70d2cc>] triggerprocessregex+0xc0/0x110 [<0000000066737a4c>] eventtriggerwrite+0x75/0xd0 [<000000007341e40c>] vfswrite+0xbb/0x2a0 [<0000000087fde4c2>] ksyswrite+0x59/0xd0 [<00000000581e9cdf>] dosyscall64+0x3a/0x80 [<00000000cf3b065c>] entrySYSCALL64afterhwframe+0x46/0xb0

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

list: fix a data-race around ep->rdllist

eppoll() first calls epeventsavailable() with no lock held and checks if ep->rdllist is empty by listemptycareful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.

Note INITLISTHEADRCU() already has the annotation for both prev and next.

Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless epeventsavailable(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epollwait()") made some epeventsavailable() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last epeventsavailable() lockless.

BUG: KCSAN: data-race in doepollwait / doepollwait

write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INITLISTHEAD include/linux/list.h:38 [inline] listspliceinit include/linux/list.h:492 [inline] epstartscan fs/eventpoll.c:622 [inline] epsendevents fs/eventpoll.c:1656 [inline] eppoll fs/eventpoll.c:1806 [inline] doepollwait+0x4eb/0xf40 fs/eventpoll.c:2234 doepollpwait fs/eventpoll.c:2268 [inline] dosysepollpwait fs/eventpoll.c:2281 [inline] sesysepollpwait+0x12b/0x240 fs/eventpoll.c:2275 x64sysepollpwait+0x74/0x80 fs/eventpoll.c:2275 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x44/0xd0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae

read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: listemptycareful include/linux/list.h:329 [inline] epeventsavailable fs/eventpoll.c:381 [inline] eppoll fs/eventpoll.c:1797 [inline] doepollwait+0x279/0xf40 fs/eventpoll.c:2234 doepollpwait fs/eventpoll.c:2268 [inline] dosysepollpwait fs/eventpoll.c:2281 [inline] sesysepollpwait+0x12b/0x240 fs/eventpoll.c:2275 x64sysepollpwait+0x74/0x80 fs/eventpoll.c:2275 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x44/0xd0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae

value changed: 0xffff88810480c7d0 -> 0xffff888103c15098

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

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

wifi: brcmfmac: Check the return value of ofpropertyreadstringindex()

Somewhen between 6.10 and 6.11 the driver started to crash on my MacBookPro14,3. The property doesn't exist and 'tmp' remains uninitialized, so we pass a random pointer to devmkstrdup().

The crash I am getting looks like this:

BUG: unable to handle page fault for address: 00007f033c669379 PF: supervisor read access in kernel mode PF: errorcode(0x0001) - permissions violation PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1 Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024 RIP: 0010:strlen+0x4/0x30 Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? die+0x23/0x70 ? pagefaultoops+0x149/0x4c0 ? rawspinrqlocknested+0xe/0x20 ? schedbalancenewidle+0x22b/0x3c0 ? updateloadavg+0x78/0x770 ? excpagefault+0x6f/0x150 ? asmexcpagefault+0x26/0x30 ? pfxpciconf1write+0x10/0x10 ? strlen+0x4/0x30 devmkstrdup+0x25/0x70 brcmfofprobe+0x273/0x350 [brcmfmac]

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

ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params

Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.

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

fbdev: hypervfb: Allow graceful removal of framebuffer

When a Hyper-V framebuffer device is unbind, hypervfb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released.

[ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fbinfo.c:70 framebufferrelease+0x2c/0x40 < snip > [ 44.111289] Call Trace: [ 44.111290] <TASK> [ 44.111291] ? showregs+0x6c/0x80 [ 44.111295] ? warn+0x8d/0x150 [ 44.111298] ? framebufferrelease+0x2c/0x40 [ 44.111300] ? reportbug+0x182/0x1b0 [ 44.111303] ? handlebug+0x6e/0xb0 [ 44.111306] ? excinvalidop+0x18/0x80 [ 44.111308] ? asmexcinvalidop+0x1b/0x20 [ 44.111311] ? framebufferrelease+0x2c/0x40 [ 44.111313] ? hvfbremove+0x86/0xa0 [hypervfb] [ 44.111315] vmbusremove+0x24/0x40 [hvvmbus] [ 44.111323] deviceremove+0x40/0x80 [ 44.111325] devicereleasedriverinternal+0x20b/0x270 [ 44.111327] ? busfinddevice+0xb3/0xf0

Fix this by moving the release of framebuffer and assosiated memory to fbops.fbdestroy function, so that framebuffer framework handles it gracefully.

While we fix this, also replace manual registrations/unregistration of framebuffer with devmregisterframebuffer.

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

powerpc/paprscm: don't requests stats with '0' sized stats buffer

Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being reported with vPMEM when paprscm probe is being called. The panic is of the form below and is observed only with following option disabled(profile) for the said LPAR 'Enable Performance Information Collection' in the HMC:

Kernel attempted to write user page (1c) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on write at 0x0000001c Faulting instruction address: 0xc008000001b90844 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c008000001b90844] drcpmemquerystats+0x5c/0x270 [paprscm] LR [c008000001b92794] paprscmprobe+0x2ac/0x6ec [paprscm] Call Trace: 0xc00000000941bca0 (unreliable) paprscmprobe+0x2ac/0x6ec [paprscm] platformprobe+0x98/0x150 reallyprobe+0xfc/0x510 driverprobedevice+0x17c/0x230 <snip> ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception

On investigation looks like this panic was caused due to a 'statbuffer' of size==0 being provided to drcpmemquerystats() to fetch all performance stats-ids of an NVDIMM. However drcpmemquerystats() shouldn't have been called since the vPMEM NVDIMM doesn't support and performance stat-id's. This was caused due to missing check for 'p->statbufferlen' at the beginning of paprscmpmucheckevents() which indicates that the NVDIMM doesn't support performance-stats.

Fix this by introducing the check for 'p->statbufferlen' at the beginning of paprscmpmucheckevents().

[1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com

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

mm/zswap: fix inconsistency when zswapstorepage() fails

Commit b7c0ccdfbafd ("mm: zswap: support large folios in zswapstore()") skips charging any zswap entries when it failed to zswap the entire folio.

However, when some base pages are zswapped but it failed to zswap the entire folio, the zswap operation is rolled back. When freeing zswap entries for those pages, zswapentryfree() uncharges the zswap entries that were not previously charged, causing zswap charging to become inconsistent.

This inconsistency triggers two warnings with following steps: # On a machine with 64GiB of RAM and 36GiB of zswap $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng $ sudo reboot

The two warnings are: in mm/memcontrol.c:163, function objcgrouprelease(): WARNONONCE(nrbytes & (PAGESIZE - 1));

in mm/pagecounter.c:60, function pagecountercancel(): if (WARNONCE(new < 0, "pagecounter underflow: %ld nrpages=%lu\n", new, nrpages))

zswapstoredpages also becomes inconsistent in the same way.

As suggested by Kanchana, increment zswapstoredpages and charge zswap entries within zswapstorepage() when it succeeds. This way, zswapentryfree() will decrement the counter and uncharge the entries when it failed to zswap the entire folio.

While this could potentially be optimized by batching objcg charging and incrementing the counter, let's focus on fixing the bug this time and leave the optimization for later after some evaluation.

After resolving the inconsistency, the warnings disappear.

[42.hyeyoo@gmail.com: refactor zswapstorepage()]