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

ACPI: LPIT: Avoid u32 multiplication overflow

In lpitupdateresidency() there is a possibility of overflow in multiplication, if tsckhz is large enough (> UINTMAX/1000).

Change multiplication to mulu32u32().

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

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

Bluetooth: l2cap: fix null-ptr-deref in l2capchantimeout

The Linux kernel CVE team has assigned CVE-2024-27399 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051300-CVE-2024-27399-afa8@gregkh/T

Fixed bug (Use-after-free in exif parsing under memory sanitizer). (CVE-2019-11050)

Fixed bug (Buffer underflow in bcshiftaddsub). (CVE-2019-11046)

A vulnerability was found in PHP versions 7.2.x below 7.2.26, 7.3.x below 7.3.13 and 7.4.0, PHP DirectoryIterator class accepts filenames with embedded \0 byte and treats them as terminating at that byte. This could lead to security vulnerabilities, e.g. in applications checking paths that the code is allowed to access.

Reference: https://bugs.php.net/bug.php?id=78863

drm/amdgpu: Fix possible NULL dereference in amdgpurasqueryerrorstatushelper()

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

ceph: fix deadlock or deadcode of misusing dget()

The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first.

But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.

An oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code.

To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates.

Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup.

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

rpmsg: virtio: Free driveroverride when rpmsgremove()

Free driveroverride when rpmsgremove(), otherwise the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsgns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] kmemcacheallocnode+0x1f8/0x320 [<000000002300d89b>] kmallocnodetrackcaller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driversetoverride+0xd0/0x164 [<000000003e9c4ea5>] rpmsgregisterdeviceoverride+0x98/0x170 [<000000001c0c89a8>] rpmsgnsregisterdevice+0x24/0x30 [<000000008bbf8fa2>] rpmsgprobe+0x2e0/0x3ec [<00000000e65a68df>] virtiodevprobe+0x1c0/0x280 [<00000000443331cc>] reallyprobe+0xbc/0x2dc [<00000000391064b1>] driverprobedevice+0x78/0xe0 [<00000000a41c9a5b>] driverprobedevice+0xd8/0x160 [<000000009c3bd5df>] deviceattachdriver+0xb8/0x140 [<0000000043cd7614>] busforeachdrv+0x7c/0xd4 [<000000003b929a36>] deviceattach+0x9c/0x19c [<00000000a94e0ba8>] deviceinitialprobe+0x14/0x20 [<000000003c999637>] busprobedevice+0xa0/0xac

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

media: cx231xx: set devicecaps for 417

The videodevice for the MPEG encoder did not set devicecaps.

Add this, otherwise the video device can't be registered (you get a WARNON instead).

Not seen before since currently 417 support is disabled, but I found this while experimenting with it.

A vulnerability in the lsi53c895a device affects the latest version of qemu. A DMA-MMIO reentrancy problem may lead to memory corruption bugs like stack overflow or use-after-free.

Last updated 31 March 2025

ext/fts3/fts3snippet.c in SQLite before 3.32.0 has a NULL pointer dereference via a crafted matchinfo() query.

hw/display/cirrusvgarop.h in QEMU (aka Quick Emulator) allows local guest OS privileged users to cause a denial of service (out-of-bounds read and QEMU process crash) via vectors related to copying VGA data via the cirrusbitbltropfwdtransp and cirrusbitbltropfwd functions.

Last updated 24 February 2025

blk-mq: fix IO hang from sbitmap wakeup race

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

tracing: Ensure visibility when inserting an element into tracingmap

Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries:

$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/trigger cat /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)

The warning looks as follows:

[ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracingmap.c:983 tracingmapsortentries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsiibft(E) iscsibootsysfs(E) rfkill(E) afpacket(E) nlsiso88591(E) nlscp437(E) vfat(E) fat(E) ena(E) tinypowerbutton(E) qemufwcfg(E) button(E) fuse(E) efipstore(E) iptables(E) xtables(E) xfs(E) libcrc32c(E) aesceblk(E) aescecipher(E) crct10difce(E) polyvalce(E) polyvalgeneric(E) ghashce(E) gf128mul(E) sm4cegcm(E) sm4ceccm(E) sm4ce(E) sm4cecipher(E) sm4(E) sm3ce(E) sm3(E) sha3ce(E) sha512ce(E) sha512arm64(E) sha2ce(E) sha256arm64(E) nvme(E) sha1ce(E) nvmecore(E) nvmeauth(E) t10pi(E) sg(E) scsimod(E) scsicommon(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppccpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracingmapsortentries+0x3e0/0x408 [ 2911.184667] lr : tracingmapsortentries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracingmapsortentries+0x3e0/0x408 [ 2911.195220] histshow+0x124/0x800 [ 2911.195692] seqreaditer+0x1d4/0x4e8 [ 2911.196193] seqread+0xe8/0x138 [ 2911.196638] vfsread+0xc8/0x300 [ 2911.197078] ksysread+0x70/0x108 [ 2911.197534] arm64sysread+0x24/0x38 [ 2911.198046] invokesyscall+0x78/0x108 [ 2911.198553] el0svccommon.constprop.0+0xd0/0xf8 [ 2911.199157] doel0svc+0x28/0x40 [ 2911.199613] el0svc+0x40/0x178 [ 2911.200048] el0t64synchandler+0x13c/0x158 [ 2911.200621] el0t64sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]---

The problem appears to be caused by CPU reordering of writes issued from tracingmapinsert().

The check for the presence of an element with a given key in this function is:

val = READONCE(entry->val); if (val && keysmatch(key, val->key, map->keysize)) ...

The write of a new entry is:

elt = getfreeelt(map); memcpy(elt->key, key, map->keysize); entry->val = elt;

The "memcpy(elt->key, key, map->keysize);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---

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

vfio/fsl-mc: Block calling interrupt handler without trigger

The eventfdctx trigger pointer of the vfiofslmcirq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between requestirq() and freeirq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive.

The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.

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

vfio/pci: Disable auto-enable of exclusive INTx IRQ

Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in requestirq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio.

Instead, invert the logic using IRQFNOAUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.

Fixed bug GHSA-h746-cjrr-wfmr (passwordverify can erroneously return true, opening ATO risk). (CVE-2024-3096)

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

xen/events: close evtchn after mapping cleanup

shutdownpirq and startuppirq are not taking the irqmappingupdatelock because they can't due to lock inversion. Both are called with the irqdesc->lock being taking. The lock order, however, is first irqmappingupdatelock and then irqdesc->lock.

This opens multiple races: - shutdownpirq can be interrupted by a function that allocates an event channel:

CPU0 CPU1 shutdownpirq { xenevtchnclose(e) startuppirq { EVTCHNOPbindpirq -> returns just freed evtchn e setevtchntoirq(e, irq) } xenirqinfocleanup() { setevtchntoirq(e, -1) } }

Assume here event channel e refers here to the same event channel number. After this race the evtchntoirq mapping for e is invalid (-1).

- startuppirq races with unbindfromirq in a similar way. Because startuppirq doesn't take irqmappingupdatelock it can grab the evtchn that unbindfromirq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchntoirq.

The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchntoirq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup.

On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvmesetupioqueues, pcifreeirq is called for every device which results in a call to shutdownpirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdownpirq and startuppirq are running potentially in parallel.

------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/eventsbase.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x8664 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvmeresetwork RIP: 0010:bindevtchntocpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? showtraceloglvl+0x1c1/0x2d9 ? showtraceloglvl+0x1c1/0x2d9 ? setaffinityirq+0xdc/0x1c0 ? diebody.cold+0x8/0xd ? die+0x2b/0x50 ? dotrap+0x90/0x110 ? bindevtchntocpu+0xdf/0xf0 ? doerrortrap+0x65/0x80 ? bindevtchntocpu+0xdf/0xf0 ? excinvalidop+0x4e/0x70 ? bindevtchntocpu+0xdf/0xf0 ? asmexcinvalidop+0x12/0x20 ? bindevtchntocpu+0xdf/0x ---truncated---

Accounts. The issue was addressed with improved checks.

Last updated 24 July 2024

Last updated 24 July 2024

After a failed cache insertion, addgetnetgrentX tries to send the non-existing response after the not-found header.

In addinnetgrX, addgetnetgrentX may have produced a NULL result, indicating a not-found status, but this is not handled in the subsequent code that prepares the record that will be sent out to the client.

Reference: https://sourceware.org/bugzilla/showbug.cgi?id=31678

An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

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

ipvs: fix uninit-value for saddr in dooutputroute4

syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to retsaddr.

[1] BUG: KMSAN: uninit-value in dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 ipvsgetoutrt+0x403/0x21d0 net/netfilter/ipvs/ipvsxmit.c:330 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e

Uninit was created at: slabpostallochook mm/slub.c:4167 [inline] slaballocnode mm/slub.c:4210 [inline] kmalloccachenoprof+0x8fa/0xe00 mm/slub.c:4367 kmallocnoprof include/linux/slab.h:905 [inline] ipvsdestdstalloc net/netfilter/ipvs/ipvsxmit.c:61 [inline] ipvsgetoutrt+0x35d/0x21d0 net/netfilter/ipvs/ipvsxmit.c:323 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e

CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---

drm/amdgpu: handle amdgpucgscreatedevice() errors in amdpowerplaycreate()

bpf: Fix deadlock between rcutaskstrace and eventmutex.