binfmtmisc: restore write access when removing an entry

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

net/smc: fix socket refcount leak in smcswitchconns()

smcswitchconns() takes a reference on the SMC socket before dropping lgr->connslock, so the connection stays alive while the CDC slot is fetched:

sockhold(&smc->sk); readunlockbh(&lgr->connslock); / pre-fetch buffer outside of sendlock, might sleep / rc = smccdcgetfreeslot(conn, tolnk, &wrbuf, NULL, &pend); if (rc) goto errout;

The errout label only drops the wrtx link reference, so this early exit returns without the matching sockput(). The second error exit is not affected, because sockput() has already run by then.

A leaked skrefcnt means the smcsock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down.

smccdcgetfreeslot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smcswitchconns() run in the first place.

Restructure so there is a single sockput() covering both outcomes, instead of adding a second one to the error path.

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]

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

ipip: fix skb leak in collectmd mode when metadatadst allocation fails

In collectmd mode ipiptunnelrcv() returns 0 without freeing the skb when iptunrxdst() fails to allocate the metadatadst. ipiprcv() and mplsiprcv() are registered as xfrmtunnel handlers, so tunnel4rcv() and tunnelmpls4rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked.

The other tunnel drivers all dispose of the packet at this point: ip6tunnel.c jumps to its drop label, ipgre.c and ip6gre.c return PACKETREJECT, which makes grercv() free the skb. Only ipip returns 0.

Jump to the existing drop label instead. It frees the skb and still returns 0, so the packet keeps being reported as consumed, which is what we want here: the outer header has already been pulled, and neither the remaining handlers nor an ICMP unreachable have any use for it.

Triggering this needs an ipip or mplsip tunnel in collectmd mode and an atomic allocation failure, which is why it has gone unnoticed.

bnx2x: fix double free in bnx2xinitfirmware() error path

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

netfilter: nftablesoffload: suppress WARNONONCE for ENOMEM in abort path

In nftflowruleoffloadabort(), WARNONONCE(err) is triggered on every error during rollback, including -ENOMEM. Memory allocation failures are expected under low-memory conditions and do not indicate a kernel bug.

Trace for example: nftflowoffloadchain() // FLOWBLOCKBIND nftflowblockchain() nftchainoffloadcmd() nftblockoffloadcmd() ->ndosetuptc() nsimsetuptc() flowblockcbsetupsimple() flowblockcballoc() // fails to -ENOMEM

The warning was reproduced on the 5.10 stable kernel under memory pressure via fault injection, but the underlying bug exists in mainline as well, as demonstrated by the ENOMEM trace above. The following splat was triggered during nftables transaction processing:

WARNING: CPU: 0 PID: 8567 at net/netfilter/nftablesoffload.c:532 nftflowruleoffloadabort net/netfilter/nftablesoffload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nftablesoffload.c:532 nftflowruleoffloadcommit+0x971/0xcd0 net/netfilter/nftablesoffload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:nftflowruleoffloadabort net/netfilter/nftablesoffload.c:532 [inline] RIP: 0010:nftflowruleoffloadcommit+0x971/0xcd0 net/netfilter/nftablesoffload.c:591 Call Trace: nftablescommit+0x3bd/0x4bd0 net/netfilter/nftablesapi.c:8604 nfnetlinkrcvbatch+0xb1e/0x1f20 net/netfilter/nfnetlink.c:509 nfnetlinkrcvskbbatch net/netfilter/nfnetlink.c:579 [inline] nfnetlinkrcv+0x3b3/0x420 net/netfilter/nfnetlink.c:597 netlinkunicastkernel net/netlink/afnetlink.c:1314 [inline] netlinkunicast+0x6cd/0xa00 net/netfilter/afnetlink.c:1340 netlinksendmsg+0x906/0xe10 net/netfilter/afnetlink.c:1919 socksendmsgnosec net/socket.c:651 [inline] socksendmsg+0x155/0x190 net/socket.c:663 syssendmsg+0x705/0x870 net/socket.c:2379 syssendmsg+0x100/0x170 net/socket.c:2433 syssendmsg+0xe9/0x1c0 net/socket.c:2462 dosyscall64+0x33/0x40 arch/x86/entry/common.c:46 entrySYSCALL64afterhwframe+0x67/0xd1

Change the condition to WARNONONCE(err && err != -ENOMEM) so that warnings are only emitted for unexpected errors. This aligns with the common kernel practice of not warning on -ENOMEM.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

HID: core: fix number/pointer type confusion on long items

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

mptcp: pm: fix memory leak from alloc-during-teardown race

mptcppmdestroy() empties msk->pm.annolist and msk->pm.userspacepmlocaladdrlist under msk->pm.lock during socket teardown, dropping the lock between the two.

A concurrent userspace PM genl ANNOUNCE on the same msk holds a sock reference via mptcptokengetsock() and, in mptcppmnlannouncedoit(), calls mptcpuserspacepmappendnewlocaladdr() and mptcppmannouncedalloc(). Both take msk->pm.lock briefly to add to their respective lists. Because the genl handler holds a sock reference, mptcppmdestroy() may run on the same msk via mptcpdisconnect(), which invokes mptcpdestroycommon() without dropping the sock refcount, before the handler completes.

If the lock acquisitions interleave such that mptcppmdestroy() empties a list first, the later alloc adds its entry to a list head that nothing else iterates for this msk, and the entry leaks. kmemleak reports both mptcppmaddaddr objects (from mptcppmannouncedalloc()) and mptcppmaddrentry objects (from mptcpuserspacepmappendnewlocaladdr()) under sustained concurrent ANNOUNCE + close load against the userspace PM.

Add an MPTCPPMDESTROYING bit in msk->pm.status, set by mptcppmdestroy() under pm.lock before the lists are emptied and checked under pm.lock by the alloc paths. Either the alloc takes pm.lock first, in which case its entry is on the list when mptcppmdestroy() frees it; or mptcppmdestroy() takes pm.lock first, in which case the later alloc observes the bit and refuses.

Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782).

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

USB: serial: option: fix slab OOB read in interrupt URB callback

The interrupt URB buffer is allocated in setupportinterruptin() based on the endpoint's wMaxPacketSize:

buffersize = usbendpointmaxp(epd); port->interruptinbuffer = kmalloc(buffersize, GFPKERNEL);

When a USB device declares wMaxPacketSize = 8 on its interrupt IN endpoint, the buffer is allocated from kmalloc-8 cache (exactly 8 bytes).

If the device sends a short packet (actuallength < wMaxPacketSize), the URB completes with status == 0 and the callback proceeds to read:

data[sizeof(struct usbctrlrequest)]

which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte buffer. This results in a slab out-of-bounds read.

Fix this by adding the missing bounds check: first verify that the actual length is large enough to contain the struct usbctrlrequest header before accessing reqpkt->bRequestType and reqpkt->bRequest, and then verify that there is an additional byte for the modem signal state before reading data[sizeof(struct usbctrlrequest)] inside the conditional. Use sizeof(reqpkt) instead of sizeof(struct usbctrlrequest) for consistency.

[ johan: use deverr(); split signals declaration and initialisation ]

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)

ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout

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

Input: hynitroncstxxx - validate touch count and finger IDs

The driver allocates maxtouchnum input slots, which are indexed from zero through maxtouchnum - 1. The current check allows a finger ID equal to maxtouchnum to reach cst3xxreportcontact(). While the input core ignores out-of-range slot indices, reporting touch data without a valid slot change corrupts the touch state of the previously active slot.

The touch count is read from the controller's report and is used to index the fixed-size report buffer without first checking its range. Reject counts larger than the supported number of touch slots before checking the trailing byte or parsing touch data.

Reject finger IDs equal to or greater than maxtouchnum, and return immediately when an invalid finger ID is encountered so that corrupt touch frames are discarded instead of reporting partial contact state.

The V821 Avaota F1 board configures the vendor driver with one touch slot, so finger ID 1 is already invalid on that device.

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

xfrm: fix xfrmstateconstruct() auth-trunc leak

attachauthtrunc() can allocate x->aalg while leaving x->props.aalgo at zero when the selected auth algorithm has no sadbalgid. One real case is cmac(aes).

xfrmstateconstruct() then treats !x->props.aalgo as "no auth algorithm attached yet" and calls attachauth(). That overwrites x->aalg and loses the first allocation. Any later failure or teardown only frees the replacement pointer.

Check whether x->aalg is already attached instead of inferring that state from x->props.aalgo.

HID: roccat: free buffered reports when destroying device

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

power: supply: bq25890: Fix powersupply reference leak

bq25890fwprobe() acquires a reference to a secondary charger using powersupplygetbyname(), but the reference is not released on later probe failures or on driver detach.

In particular, failures after bq25890fwprobe() returns successfully, such as a failure in bq25890hwinit(), also leak the reference.

Register a device-managed cleanup action immediately after acquiring the secondary charger. This releases the reference on all subsequent probe failures and on driver detach.

Found by code review.

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

power: supply: max17040: synchronize work cancellation on suspend

max17040work() requeues itself after every poll. canceldelayedwork() only cancels a pending instance and does not wait for a callback that is already running.

If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns.

Use canceldelayedworksync() to ensure polling is quiesced before suspend completes.

HID: picolcd: clamp eeprom debugfs read to bytes actually received

drm/amdgpu: disallow multiple FENCE chunks in one submit