binfmtmisc: restore write access when removing an entry

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

mailbox: mchp-ipc-sbi: Add null check for devmkasprintf()

Add a check to see if devmkasprintf() is not NULL in mchpipcgetclusteraggrirq(), returning -ENOMEM if the function failed.

drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X client is registered

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:

wifi: brcmfmac: Fix memory leak in brcmfsdioreadcontrol()

The memory allocated for buf is not freed in some of the error paths in brcmfsdioreadcontrol(). Fix that by adding vfree() calls.

[arend: rework as suggested by Johannes]

bnx2x: fix double free in bnx2xinitfirmware() error path

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.

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

smack: fix incorrect task context in smackmsgqueuemsgrcv

The smackmsgqueuemsgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task.

In the msgsnd() syscall path, if a receiver is already waiting, the pipelinedsend() optimization is used to push the message directly to the receiver task:

ipc/msg.cpipelinedsend(): smpstorerelease(&msr->rmsg, msg)

In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->rtsk, passed as the 'target' parameter):

ipc/msg.cpipelinedsend(): securitymsgqueuemsgrcv(,, target := msr->rtsk,,)

However, smackmsgqueuemsgrcv() ignores the 'target' and checks 'current':

smackmsgqueuemsgrcv(…) smkcuraccmsq(isp, MAYREADWRITE); // current task

'current' MAY satisfy smackmsgqueuemsgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy.

Test: 1) create a sysv message queue with label “foo” 2) echo "bar foo r" >/smack/load2 3) msgrcv(,,,0,MSGNOERROR) in "bar"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a "foo"-labeled task: "bar"-labeled task gets the message.

This patch fixes the issue by checking permission on the 'target' task instead of 'current'.

(2008-02-04, Casey Schaufler)

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

smb3: fix temporary data corruption in collapse range

collapse range doesn't discard the affected cached region so can risk temporarily corrupting the file data. This fixes xfstest generic/031

I also decided to merge a minor cleanup to this into the same patch (avoiding rereading inode size repeatedly unnecessarily) to make it clearer.

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.

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

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.