Brief items

Man Yue Mo: Gaining kernel code execution on an MTE-enabled Pixel 8

Man Yue Mo explains how to compromise a Pixel 8 phone even when the Arm memory-tagging extension is in use, by taking advantage of the Mali GPU.

So, by using the GPU to access physical addresses directly, I'm able to completely bypass the protection that MTE offers. Ultimately, there is no memory safe code in the code that manages memory accesses. At some point, physical addresses will have to be used directly to access memory.

Comments (3 posted)

Python announces first security releases since becoming a CNA

The Python project has announced three security releases, 3.10.14, 3.9.19, and 3.8.19. In addition to the security fixes, these releases are notable for two reasons; they are the first to make use of GitHub Actions to perform public builds instead of building artifacts "on a local computer of one of the release managers", and the first since Python became a CVE Numbering Authority (CNA).

Python release team member Łukasz Langa said that being a CNA means Python is able to "ensure the quality of the vulnerability reports is high, and that the severity estimates are accurate." It also allows Python to coordinate CVE announcements with the patched versions of Python, as it has with two CVEs addressed in these releases. CVE-2023-6597 CVE-2024-0450 describes a flaw in CPython's zipfile module that made it vulnerable to a zip-bomb exploit. CVE-2024-0450 CVE-2023-6597 is an issue with Python's tempfile.TemporaryDirectory class which could be exploited to modify permissions of files referenced by symbolic links. Users of affected versions should upgrade soon.

Comments (none posted)

Kernel release status

The 6.9 merge window remains open; it can be expected to close on March 24.

Stable updates: 6.8.1, 6.7.10, 6.6.22, 6.1.82, 5.15.152, 5.10.213, 5.4.272, and 4.19.310 were released on March 15.

Comments (none posted)

Quote of the week

Linus would, of course, be the real authority on this, but if someone would ask me what the fundamental design philosophies of the Linux kernel are -- the design decisions which make Linux Linux, if you will -- I would say:

1. Non-dynamic kernel memory
2. Permanent mapping of physical memory
3. Kernel API modeled closely after the POSIX API (no complicated user space layers)
4. Fast system call entry/exit (a necessity for a kernel API based on simple system calls)
5. Monolithic (but modular) kernel environment (not cross-privilege, coroutine or message passing)

— H. Peter Anvin

Comments (none posted)

Firefox 124.0 released

Version 124.0 of the Firefox browser is out. Changes include support for "caret browsing mode" in the PDF viewer and the ability to control the sorting of tabs in the Firefox View screen.

Comments (9 posted)

GNOME 46 released

Version 46 of the GNOME desktop has been released. "GNOME 46 is code-named 'Kathmandu', in recognition of the amazing work done by the organizers of GNOME.Asia 2023." Significant changes include a new global search feature, enhancements to the Files app, improved remote login support, and more.

Comments (12 posted)

Mitchell: Today we launched Flox 1.0

Zach Mitchell has announced the 1.0 release of Flox, a tool that lets its users install packages from nixpkgs inside portable virtual environments, and share those virtual environments with others as an alternative to Docker-style containers. Flox is based on Nix but allows users to skip learning how to work with the Nix language:

With Flox we're providing a substantially better user experience. We provide the suite of package manager functionality with install, uninstall, etc, but we also provide an entire new suite of functionality with the ability to share environments via flox push, flox pull, and flox activate --remote.

Flox is GPLv2-licensed, and releases are available as RPMs and Debian packages for x86_64 and arm64 systems.

Comments (3 posted)

Development quote of the week

Even for personal hobby projects, there is often a strong urge to get something working as soon as possible rather than taking one's time to do things well, but at least that's an internal urge, not external pressure. Even so, the end result is the same: software that's harder to change later on, when bugs are found, requirements change, or the software needs to be adapted to changes in the surrounding system or ecosystem.

I am not alone in seeing the problem. I don't think it can be solved, unless the economic incentives are radically changed. It's on individual developers to try to reduce maintenance costs surreptitiously, when they can, as a kind of preemptive guerrilla maintenance.

— Lars Wirzenius

Comments (2 posted)