A use-after-free flaw was found in vhostnetsetbackend in drivers/vhost/net.c in virtio network subcomponent in the Linux kernel due to a double fget. This flaw could allow a local attacker to crash the system, and could even lead to a kernel information leak problem.

In kernel/bpf/hashtab.c in the Linux kernel through 5.13.8, there is an integer overflow and out-of-bounds write when many elements are placed in a single bucket. NOTE: exploitation might be impractical without the CAPSYSADMIN capability.

A vulnerability was found in Linux Kernel, where a type confusion problem in checkmapfunccompatibility() may lead to free arbitrary kernel memory.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=5b029a32cfe4600f5e10e36b41778506b90fd4de https://www.zerodayinitiative.com/advisories/ZDI-21-1148/

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

staging: rtl8723bs: fix mismatched free of HalData in rtwsdioif1init()

padapter->HalData is allocated via vzalloc(), but incorrectly freed using kfree() in the rtwsdioif1init() error path. Using kfree() to release this vmalloc-backed buffer can lead to memory corruption.

Use rtwhaldatadeinit() to pair the free correctly and free HalData with vfree().

The bug was first flagged by an experimental static analysis tool we are developing for kernel memory-management bugs. Manual inspection confirms that the issue is still present in current mainline.

An x8664 allyesconfig build showed no new warnings. As we do not have suitable RTL8723BS SDIO hardware to test with, no runtime testing was able to be performed.

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

Bluetooth: L2CAP: Fix possible crash on l2capecredconnrsp

If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2capchandel may invalidate the tmp cursor created by listforeachentrysafe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.

Calling l2capchanclone directly may still lead to l2capchandel so instead schedule l2capchantimeout with delay 0 to close the channel asynchronously.

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

sctp: fix race between sctpwaitforconnect and peeloff

sctpwaitforconnect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTPSOCKOPTPEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctpwaitforconnect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctpdatamsgfromuser().

Add the same sk != asoc->base.sk check that sctpwaitforsndbuf() already has, returning an error if the association was migrated while we slept.

iouring use workflags to determine which identity need to grab from the calling process to make sure it is consistent with the calling process when executing IORINGOP. Some operations are missing some types, which can lead to incorrect reference counts which can then lead to a double free. We recommend upgrading the kernel past commit df3f3bb5059d20ef094d6b2f0256c4bf4127a859

A use-after-free flaw was found in btsdioremove in drivers\bluetooth\btsdio.c in the Linux Kernel. A call to btsdioremove with an unfinished job may cause a race problem which leads to a UAF on hdev devices.

Bluetooth: l2cap: Add missing chan lock in l2capecredreconfrsp

dma-buf: heaps: Fix off-by-one in CMA heap fault handler

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

vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans

During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.

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

ALSA: usb-audio: Fix out of bounds reads when finding clock sources

The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.

For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.

For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.

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

ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices

A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usbgetconfiguration for allocating dev->config.

This can lead to out-of-bounds accesses later, e.g. in usbdestroyconfiguration.

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

posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()

If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().

If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.

Add the tsk->exitstate check into runposixcputimers() to fix this.

This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.

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

RDMA/vmwpvrdma: Fix double free on pvrdmaallocucontext() error path

Sashiko points out that pvrdmauarfree() is already called within pvrdmadeallocucontext(), so calling it before triggers a double free.

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

Bluetooth: l2cap: Check encryption key size on incoming connection

This is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bit

This tests the security key with size from 1 to 15 bytes while the Security Mode 4 Level 4 requests 16 bytes key size.

Currently PTS fails with the following logs: - expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt), but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information available

And HCI logs: < HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7 ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64 < ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)

crypto: algifaead - Revert to operating out-of-place

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

nvme-pci: ensure we're polling a polled queue

A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.

esp: fix skb leak with espintcp and async crypto

afkey: validate families in pfkeysendmigrate()

ext4: avoid journaling sb update on error if journal is destroying

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]

ALSA: aloop: Fix peer runtime UAF during format-change stop

bpf: Free reuseport cBPF prog after RCU grace period.

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

USB: serial: ioti: fix heap overflow in getmanufinfo()

getmanufinfo() reads le16tocpu(romdesc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmallocobj(), which is sizeof(struct edgetimanufdescriptor) = 10 bytes.

The Size field comes from the device and is only validated (in checki2cimage()) to make sure the descriptor fits within TIMAXI2CSIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.

validcsum() is called after readrom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling readrom().

[ johan: amend commit message; also check for short descriptors ]

A flaw in the Linux kernel's ebtables SNAT target allows writing to shared memory pages when rewriting ARP sender hardware addresses without ensuring writability, potentially causing file/memory corruption or denial of service.

crypto: afalg - Disallow concurrent writes in afalgsendmsg

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

media: dvbdev: prevent the risk of out of memory access

The dvbdev contains a static variable used to store dvb minors.

The behavior of it depends if CONFIGDVBDYNAMICMINORS is set or not. When not set, dvbregisterdevice() won't check for boundaries, as it will rely that a previous call to dvbregisteradapter() would already be enforcing it.

On a similar way, dvbdeviceopen() uses the assumption that the register functions already did the needed checks.

This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity.

So, add explicit guards to prevent potential risk of OOM issues.

An issue was discovered in l2capsockrelease in net/bluetooth/l2capsock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled.

A flaw in the Linux Kernel found. There are use-after-free vulnerabilities in drivers/media/rc/eneir.c of linux that allow attacker to crash linux kernel without any privilege by detaching rc device.

When the rc device is detaching, function eneremove() will be called. But the synchronizations in eneremove() are bad. The situations that may lead to race conditions are shown below.

Firstly, the rx receiver is disabled with enerxdisable() before rcunregisterdevice() in eneremove(), which means it can be enabled again if a process opens /dev/lirc0 between enerxdisable() and rcunregisterdevice().

(cleanup routine) | (open routine) eneremove() | enerxdisable(dev); | eneopen() | enerxenable(dev); //re-enable!

Secondly, the irqaction descriptor is freed by freeirq() before the rc device is unregistered, which means irqaction descriptor may be accessed again after it is deallocated.

(free routine) | (use routine) eneremove() | enerxenable() freeirq(dev->irq, ...); //FREE | enerxenablehw() | enewritereg(..., dev->irq << 1) //USE |

Thirdly, the timer can call enetxsample() that can write to the io ports, which means the io ports could be accessed again after they are deallocated by releaseregion().

(free routine) | (use routine) eneremove() | enetxsample() releaseregion(dev->hwio, ...); //FREE | enewritereg() | outb(..., dev->hwio + ENEIO) //USE

Fourthly, there is no function to cancel txsimtimer in eneremove(), the timer handler enetxirqsim() could race with eneremove(). As a result, the UAF bugs could happen, the process is shown below.

(free routine) | (use routine) | modtimer(&dev->txsimtimer, ..) eneremove() | (wait a time) kfree(dev) //FREE | enetxirqsim() | dev->hwlock //USE | enetxsample(dev) //USE

------------------------------------------

Reference: https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17