fbdev: fbcon: fix out-of-bounds read in errout of fbcondosetfont()

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

ipv4: account for fraggap on the paged allocation path

In ipappenddata(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as

alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen;

datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skbcopyandcsumbits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount.

The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen.

After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.

In ip6appenddata(), when the paged-allocation branch is taken (MSGMORE / NETIFFSG / large fraglen), alloclen and pagedlen are computed as

alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen;

datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skbsharedinfo.

An unprivileged user can trigger this via a UDPv6 socket using MSGMORE together with MSGSPLICEPAGES.

The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix ip6appenddata()'s handling of MSGSPLICEPAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSGSPLICEPAGES to proceed in this case, making the corruption triggerable.

The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen.

After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSGSPLICEPAGES case, remove the MSGSPLICEPAGES exception from the negative copy check.

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

udp: clear skb->dev before running a sockmap verdict

On the UDP receive path skb->dev is repurposed as devscratch (the truesize/state cache set by udpsetdevscratch()), through the union { struct netdevice dev; unsigned long devscratch; } in skbuff.

When a UDP socket is in a sockmap, skdataready is skpsockverdictdataready(), which calls udpreadskb() -> recvactor() (skpsockverdictrecv) to run the attached SKSKB verdict program in softirq. If that program calls a socket-lookup helper (bpfsklookuptcp/udp, bpfskclookuptcp), bpfskclookup() does:

if (skb->dev) callernet = devnet(skb->dev);

skb->dev still holds the devscratch value (a non-NULL integer), so devnet() dereferences it as a struct netdevice and the kernel takes a general protection fault on a non-canonical address in softirq:

Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpfskclookup net/core/filter.c:7033 [inline] RIP: 0010:bpfsklookup+0x45/0x160 net/core/filter.c:7047 Call Trace: <IRQ> bpfprog4675cb904b7071f8+0x12e/0x14e bpfprogrunpinoncpu+0xc6/0x1f0 skpsockverdictrecv+0x1ba/0x350 udpreadskb+0x31a/0x370 skpsockverdictdataready+0x2e3/0x600 udpenqueuescheduleskb+0x4c8/0x650 udpv6queuercvoneskb+0x3ec/0x740 udp6unicastrcvskb+0x11d/0x140 ip6protocoldeliverrcu+0x61e/0x950 ip6inputfinish+0xa9/0x150 NFHOOK+0x286/0x2f0 ip6input+0x117/0x220 NFHOOK+0x286/0x2f0 netifreceiveskb+0x85/0x200 processbacklog+0x374/0x9a0 napipoll+0x4f/0x1c0 netrxaction+0x3b0/0x770 handlesoftirqs+0x15a/0x460 dosoftirq+0x57/0x80 </IRQ>

The rmem charge that devscratch accounted for is released by skbrecvudp() on dequeue, just above, so the scratch is dead by the time recvactor() runs. Clear skb->dev so bpfskclookup() falls back to socknet(skb->sk), which skbsetownersksafe() set just above.

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

net: tls: fix strparser anchor skb leak on offload RX setup failure

When tlssetdeviceoffloadrx() fails at tlsdevadd(), the error path calls tlsswfreeresourcesrx() to clean up the SW context that was initialized by tlssetswoffload(). This function calls tlsswreleaseresourcesrx() (which stops the strparser via tlsstrpstop()) and tlsswfreectxrx() (which kfrees the context), but never frees the anchor skb that was allocated by allocskb(0) in tlsstrpinit().

Note that tlsswfreeresourcesrx() is exclusively used for this "failed to start offload" code path, there's no other caller.

The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb.

The normal close path in tlsskprotoclose() handles cleanup by calling tlsswstrparserdone() (which calls tlsstrpdone()) after dropping the socket lock, because tlsstrpdone() does cancelworksync() and the strparser work handler takes the socket lock.

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

KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic

kvms390pciaifenable(), kvms390pciaifdisable(), and aenhostforward() index the GAIT by manually multiplying the index with sizeof(struct zpcigaite).

Since aift->gait is already a struct zpcigaite pointer, this double-scales the offset, accessing element aisb16 instead of aisb.

This causes out-of-bounds accesses when aisb >= 32 (with ZPCINRDEVICES=512)

Fix by removing the erroneous sizeof multiplication.

flowdissector: do not dissect PPPoE PFC frames

drm/amdgpu/vcn4: Prevent OOB reads when parsing IB

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

wifi: mac80211: remove station if connection prep fails

If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "newsta" is already being removed, so that doesn't need changes.

This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.

Bluetooth: hciconn: fix potential UAF in createbigsync

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

net: gro: don't merge zcopy skbs

skbgroreceive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFLMANAGEDFRAGREFS flag.

When SKBFLMANAGEDFRAGREFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.

When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.

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

cifs: Fix locking usage for tcon fields

We used to use the cifstcpseslock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srvlock, seslock and tclock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization.

There were still a couple of uses of cifstcpseslock to provide tcon fields. In this patch, I've replaced them with tclock.

drm/amdgpu: Fix fence put before wait in amdgpuamdkfdsubmitib

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

spi: fix use-after-free on controller registration failure

Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses.

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

bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing

struct bpfplt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.

Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in buildplt() fails to ensure that target lands on an 8-byte boundary.

This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITEONCE() in bpfarchtextpoke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.

Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpfjitbinarypackalloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in buildplt() to correctly align the target field.

bpf: Fix a UAF issue in bpftrampolinelinkcgroupshim

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

scsi: core: Fix refcount leak for tagsetrefcnt

This leak will cause a hang when tearing down the SCSI host. For example, iscsid hangs with the following call trace:

[130120.652718] scsiallocsdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured

PID: 2528 TASK: ffff9d0408974e00 CPU: 3 COMMAND: "iscsid" #0 [ffffb5b9c134b9e0] schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] scheduletimeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] waitforcommon at ffffffff8606674f #4 [ffffb5b9c134bb10] scsiremovehost at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsiswtcpsessiondestroy at ffffffffc03031c4 [iscsitcp] #6 [ffffb5b9c134bb48] iscsiifrecvmsg at ffffffffc0292692 [scsitransportiscsi] #7 [ffffb5b9c134bb98] iscsiifrx at ffffffffc02929c2 [scsitransportiscsi] #8 [ffffb5b9c134bbf0] netlinkunicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlinksendmsg at ffffffff85e554ef

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

efivarfs: fix error propagation in efivarentryget()

efivarentryget() always returns success even if the underlying efivarentryget() fails, masking errors.

This may result in uninitialized heap memory being copied to userspace in the efivarfsfileread() path.

Fix it by returning the error from efivarentryget().

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

blk-mq: use quiesced elevator switch when reinitializing queues

The hctx's runwork may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally.

nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blkmqrunworkfn RIP: 0010:kyberhaswork+0x29/0x70

...

Call Trace: blkmqdodispatchsched+0x83/0x2b0 blkmqscheddispatchrequests+0x12e/0x170 blkmqscheddispatchrequests+0x30/0x60 blkmqrunhwqueue+0x2b/0x50 processonework+0x1ef/0x380 workerthread+0x2d/0x3e0

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

bpf: Propagate error from htablockbucket() to userspace

In htabmaplookupanddeletebatch() if htablockbucket() returns -EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current bucketcnt is greater than bucketsize or zero.

Fixing it by stopping batch operation and returning -EBUSY when htablockbucket() fails, and the application can retry or skip the busy batch as needed.

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

drm/i915: mark requests for GuC virtual engines to avoid use-after-free

References to i915requests may be trapped by userspace inside a syncfile or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible extra bit has been added to rq->executionmask, for marking virtual engines.

(cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)

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

ublk: fail to start device if queue setup is interrupted

In ublkctrlstartdev(), if waitforcompletioninterruptible() is interrupted by signal, queues aren't setup successfully yet, so we have to fail UBLKCMDSTARTDEV, otherwise kernel oops can be triggered.

Reported by German when working on qemu-storage-deamon which requires single thread ublk daemon.

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

scsi: iscsi: iscsitcp: Fix null-ptr-deref while calling getpeername()

Fix a NULL pointer crash that occurs when we are freeing the socket at the same time we access it via sysfs.

The problem is that:

1. iscsiswtcpconngetparam() and iscsiswtcphostgetparam() take the frwdlock and do sockhold() then drop the frwdlock. sockhold() does a get on the "struct sock".

2. iscsiswtcpreleaseconn() does sockfdput() which does the last put on the "struct socket" and that does sockrelease() which sets the sock->ops to NULL.

3. iscsiswtcpconngetparam() and iscsiswtcphostgetparam() then call kernelgetpeername() which accesses the NULL sock->ops.

Above we do a get on the "struct sock", but we needed a get on the "struct socket". Originally, we just held the frwdlock the entire time but in commit bcf3a2953d36 ("scsi: iscsi: iscsitcp: Avoid holding spinlock while calling getpeername()") we switched to refcount based because the network layer changed and started taking a mutex in that path, so we could no longer hold the frwdlock.

Instead of trying to maintain multiple refcounts, this just has us use a mutex for accessing the socket in the interface code paths.

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

drm/nouveau: fix a use-after-free in nouveaugemprimeimportsgtable()

nouveauboinit() is backed by ttmboinit() and ferries its return code back to the caller. On failures, ttm will call nouveaubodelttm() and free the memory.Thus, when nouveauboinit() returns an error, the gem object has already been released. Then the call to nouveauboref() will use the freed "nvbo->bo" and lead to a use-after-free bug.

We should delete the call to nouveauboref() to avoid the use-after-free.

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

cxl/acpi: Fix a use-after-free in cxlparsecfmws()

KASAN and KFENCE detected an user-after-free in the CXL driver. This happens in the cxldecoderadd() fail path. KASAN prints the following error:

BUG: KASAN: slab-use-after-free in cxlparsecfmws (drivers/cxl/acpi.c:299)

This happens in cxlparsecfmws(), where putdevice() is called, releasing cxld, which is accessed later.

Use the local variables in the deverr() instead of pointing to the released memory. Since the deverr() is printing a resource, change the open coded print format to use the %pr format specifier.

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

efi: ssdt: Don't free memory if ACPI table was loaded successfully

Amadeusz reports KASAN use-after-free errors introduced by commit 3881ee0b1edc ("efi: avoid efivars layer when loading SSDTs from variables"). The problem appears to be that the memory that holds the new ACPI table is now freed unconditionally, instead of only when the ACPI core reported a failure to load the table.

So let's fix this, by omitting the kfree() on success.

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

scsi: libsas: Fix use-after-free bug in smpexecutetasksg()

When executing SMP task failed, the smpexecutetasksg() calls deltimer() to delete "slowtask->timer". However, if the timer handler sastaskinternaltimedout() is running, the deltimer() in smpexecutetasksg() will not stop it and a UAF will happen. The process is shown below:

(thread 1) | (thread 2) smpexecutetasksg() | sastaskinternaltimedout() ... | deltimer() | ... | ... sasfreetask(task) | kfree(task->slowtask) //FREE| | task->slowtask->... //USE

Fix by calling deltimersync() in smpexecutetasksg(), which makes sure the timer handler have finished before the "task->slowtask" is deallocated.

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

rpmsg: char: Avoid double destroy of default endpoint

The rpmsgdevremove() in rpmsgcore is the place for releasing this default endpoint.

So need to avoid destroying the default endpoint in rpmsgchrdeveptdevdestroy(), this should be the same as rpmsgeptdevrelease(). Otherwise there will be double destroy issue that ept->refcount report warning:

refcountt: underflow; use-after-free.

Call trace: refcountwarnsaturate+0xf8/0x150 virtiorpmsgdestroyept+0xd4/0xec rpmsgdevremove+0x60/0x70

The issue can be reproduced by stopping remoteproc before closing the /dev/rpmsgX.

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

net/smc: fix one NULL pointer dereference in smcibissgneedsync()

BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smchswq smclistenwork [smc] RIP: 0010:smcibissgneedsync+0x9e/0xd0 [smc] ... Call Trace: <TASK> smcrbufmaplink+0x211/0x2a0 [smc] smcbufcreate+0x522/0x970 [smc] smcbufcreate+0x3a/0x110 [smc] smcfindrdmav2deviceserv+0x18f/0x240 [smc] ? smcvlanbytcpsk+0x7e/0xe0 [smc] smclistenfinddevice+0x1dd/0x2b0 [smc] smclistenwork+0x30f/0x580 [smc] processonework+0x18c/0x340 workerthread+0x242/0x360 kthread+0xe7/0x220 retfromfork+0x13a/0x160 retfromforkasm+0x1a/0x30 </TASK>

If the software RoCE device is used, ibdev->dmadevice is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems.

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

Bluetooth: hcisysfs: Fix attempting to call deviceadd multiple times

deviceadd shall not be called multiple times as stated in its documentation:

'Do not call this routine or deviceregister() more than once for any device structure'

Syzkaller reports a bug as follows [1]: ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> listadd include/linux/list.h:69 [inline] listaddtail include/linux/list.h:102 [inline] kobjksetjoin lib/kobject.c:164 [inline] kobjectaddinternal+0x18f/0x8f0 lib/kobject.c:214 kobjectaddvarg lib/kobject.c:358 [inline] kobjectadd+0x150/0x1c0 lib/kobject.c:410 deviceadd+0x368/0x1e90 drivers/base/core.c:3452 hciconnaddsysfs+0x9b/0x1b0 net/bluetooth/hcisysfs.c:53 hcilecisestabilishedevt+0x57c/0xae0 net/bluetooth/hcievent.c:6799 hcilemetaevt+0x2b8/0x510 net/bluetooth/hcievent.c:7110 hcieventfunc net/bluetooth/hcievent.c:7440 [inline] hcieventpacket+0x63d/0xfd0 net/bluetooth/hcievent.c:7495 hcirxwork+0xae7/0x1230 net/bluetooth/hcicore.c:4007 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306 </TASK>