BPF arenas are areas of memory where the verifier can safely relax its checking of pointers, allowing programmers to write arbitrary data structures in BPF. Emil Tsalapatis reported on how his team has used arenas in writing sched_ext schedulers at the 2025 Linux Storage, Filesystem, Memory-Management, and BPF Summit. His biggest complaint was about the fact that kernel pointers can't be stored in BPF arenas — something that the BPF developers hope to address, although there are some implementation problems that must be sorted out first.

Security updates have been issued by Debian (libeconf and rubygems), Fedora (libxmp), Gentoo (glibc), Oracle (java-1.8.0-openjdk, kernel, libxslt, and virtuoso-opensource), SUSE (augeas, git-lfs, kanidm, and tomcat10), and Ubuntu (linux-lts-xenial).

The SUSE Security Team has published an article detailing several security issues it has uncovered with GNU Screen. This includes a local root exploit when Screen is shipped setuid-root, as it is in some Linux and BSD distributions. The security team also reports problems in coordinating disclosure with the upstream Screen project.

We are not satisfied with how this coordinated disclosure developed, and we will try to be more attentive to such problematic situations early on in the future. This experience also sheds light on the overall situation of Screen upstream. It looks like it suffers from a lack of manpower and expertise, which is worrying for such a widespread open source utility. We hope this publication can help to draw attention to this and to improve this situation in the future.

The article includes a table of operating systems, screen versions, and which vulnerabilities they may be affected by.

The Guix project has announced that it is migrating all of its Git repositories, as well as bug tracking and patch tracking, from Savannah to the Codeberg Git forge.

As a user, the main change is that your channels.scm configuration files, if they refer to the git.savannah.gnu.org URL, should be changed to refer to https://codeberg.org/guix/guix.git once migration is complete. But don't worry: guix pull will tell you if/when you need to update your config files and the old URL will remain a mirror for at least a year anyway.

The motivation for the move, which is spelled out in a Guix Consensus Document (GCD), is to improve the contribution experience and improve quality assurance efforts. Migration of Git repositories should be completed by June 7, though they will continue to be mirrored on Savannah until "at least" May 2026. LWN covered Guix in February 2024.

The announcement of the openSUSE Leap 16.0 beta contained something of a surprise—along with the usual set of changes and updates, it informed the community of the retirement of "the traditional YaST stack" from Leap. The YaST ("Yet another Setup Tool") installation and configuration utility has been a core part of the openSUSE distribution since its inception in 2005, and part of SUSE Linux since 1996. It will not, immediately, be removed from the openSUSE Tumbleweed rolling-release distribution, but its future is uncertain and its fate is up to the larger community to decide.

Security updates have been issued by Debian (libbson-xs-perl, postgresql-13, redis, and simplesamlphp), Fedora (chromium, deluge, epiphany, golang-github-nats-io-nkeys, libxmp, nodejs22, perl-Compress-Raw-Lzma, php-adodb, python-h11, and xz), Gentoo (firefox, NVIDIA Drivers, Orc, PAM, and thunderbird), Mageia (libreoffice, python-django, and transfig), Red Hat (emacs, firefox, python39:3.9, and thunderbird), SUSE (bird3, freetype2, ldap-proxy, libmosquitto1, and ruby3.4-rubygem-rack), and Ubuntu (linux, linux-aws, linux-kvm, linux-aws, and linux-fips).

Linus has released 6.15-rc6 for testing.

Everything still looks fairly normal - we've got a bit more commits than we did in rc5, which isn't the trend I want to see as the release progresses, but the difference isn't all that big and it feels more like just the normal noise in timing fluctuation in pull requests of fixes than any real signal.

So I won't worry about it. We've got another two weeks to go in the normal release schedule, and it still feels like everything is on track.

Those of us who have spent our lives playing with computers naturally see the appeal of deploying them though the home for both data acquisition and automation. But many of us who have watched the evolution of the technology industry are increasingly unwilling to entrust critical household functions to cloud-based servers run by companies that may not have our best interests at heart. The Apache-licensed Home Assistant project offers a welcome alternative: locally controlled automation with free software. This two-part series covers roughly a year of Home Assistant use, starting with a set of overall observations about the project.

Lance Albertson writes that the Oregon State University Open Source Lab has been funded for the next year, following his announcement in April that the future of OSL was in jeopardy. OSL is now focusing on becoming self-sustainable long term.

The recent support was amazing for our immediate team needs. But for the OSL to thrive long-term, we need a sustainable financial foundation. This is crucial, as the university expects units like ours to become self-sufficient beyond this current year.

So, our big focus this next year is locking in ongoing support – think annualized pledges, different kinds of regular income, and other recurring help. This is vital, especially with potential new data center costs and hardware needs. Getting this right means we can stop worrying about short-term funding and plan for the future: investing in our tech and people, growing our awesome student programs, and serving the FOSS community. We're looking for partners, big and small, who get why foundational open source infrastructure matters and want to help us build this sustainable future together.

Greg Kroah-Hartman has announced the release of the 6.14.6, 6.12.28, 6.6.90, 6.1.138, and 5.15.182 stable kernel versions.

Security updates have been issued by Debian (fossil, libapache2-mod-auth-openidc, and request-tracker4), Fedora (thunderbird), Mageia (firefox and thunderbird), SUSE (389-ds, apparmor, cargo-c, chromium, go1.24, govulncheck-vulndb, java-1_8_0-openjdk, kanidm, libsoup, mozjs102, openssl-1_1, openssl-3, python-Django, sccache, tealdeer, tomcat, transfig, wasm-bindgen, and wireshark), and Ubuntu (libreoffice and python-h11).

The GNOME Foundation has announced the hiring of Steven Deobald as its new executive director.

Steven has been a GNOME user since 2002 and has been involved in numerous free software initiatives throughout his career. His professional background spans technical leadership, cooperative business development, and nonprofit work. Having worked with projects like XTDB and Endatabas, he brings valuable experience in open source product development. Based in Halifax, Canada, Steven is well-positioned to collaborate with our global community across time zones.

The famfs filesystem is meant to provide a shared-memory filesystem for large data sets that are accessed for computations by multiple systems. It was developed by John Groves, who led a combined filesystem and memory-management session at the 2025 Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF) to discuss it. The session was a follow-up to the famfs session at last year's summit, but it was also meant to discuss whether the kernel's direct-access (DAX) mechanism, which is used by famfs, could be replaced in the filesystem by using other kernel features.

Security updates have been issued by Debian (chromium, libapache2-mod-auth-openidc, mariadb-10.5, and openssh), Red Hat (osbuild-composer), Slackware (mariadb), SUSE (apache2-mod_auth_openidc, glib2, ImageMagick, libsoup, libsoup2, libva, openvpn, sqlite3, and weblate), and Ubuntu (libsoup3, php-horde-css-parser, and python-django).

The openSUSE project has posted a detailed explanation on why the Deepin Desktop has been removed from the distribution; it comes down to a history of security problems and a deliberate bypass (by the packager) of openSUSE's security review.

Perhaps tired of waiting, the packager decided to try a different avenue to get the remaining Deepin components into openSUSE skirting the review requirements. In January 2025, during routine reviews, we stumbled upon the deepin-feature-enable package, which was introduced on 2021-04-27 without consulting us or even informing us. This innocently named package implements a "license agreement dialog" which basically explains that the SUSE security team has doubts about the security of Deepin, but to properly use Deepin, certain components need to be installed anyway. Thus, if the user does not care about security then "the license" should be accepted.

Lukas Fittl writes in detail on the pganalyze blog about the asynchronous I/O capability coming with the PostgreSQL 18 release.

Asynchronous I/O delivers the most noticeable gains in cloud environments where storage is network-attached, such as Amazon EBS volumes. In these setups, individual disk reads often take multiple milliseconds, introducing substantial latency compared to local SSDs.

With traditional synchronous I/O, each of these reads blocks query execution until the data arrives, leading to idle CPU time and degraded throughput. By contrast, asynchronous I/O allows Postgres to issue multiple read requests in parallel and continue processing while waiting for results. This reduces query latency and enables much more efficient use of available I/O bandwidth and CPU cycles.

Inside this week's LWN.net Weekly Edition:

• Front: Debian and essential packages; Custom BPF OOM killers; Speculation barriers for BPF programs; More LSFMM+BPF 2025 coverage.
• Briefs: Deepin on openSUSE; AUTOSEL; Mission Center 1.0.0; OASIS ODF; Redis license; USENIX ATC; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

Version 2025.5 of the Home Assistant home automation system has been released. With this release, the project is celebrating two million active installations. Changes include improvements to the backup system, Z-Wave Long Range support, a number of new integrations, and more.

Anton Protopopov led a short discussion at the 2025 Linux Storage, Filesystem, Memory-Management, and BPF Summit about amount of memory used by hash tables in BPF programs. He thinks that the current memory layout is inefficient, and wants to split the structure that holds table entries into two variants for different kinds of maps. When that proposal proved uncontroversial, he also took the chance to talk about a bug in BPF's call instruction.

The SUSE Security Team has announced the removal of the Deepin Desktop from openSUSE due to violations of the project's packaging policy.

The discovery of the bypass of the security whitelistings via the deepin-feature-enable package marks a turning point in our assessment of Deepin. We don't believe that the openSUSE Deepin packager acted with bad intent when he implemented the "license agreement" dialog to bypass our whitelisting restrictions. The dialog itself makes the security concerns we have transparent, so this does not happen in a sneaky way, at least not towards users. It was not discussed with us, however, and it violates openSUSE packaging policies. Beyond the security aspect, this also affects general packaging quality assurance: the D-Bus configuration files and Polkit policies installed by the deepin-feature-enable package are unknown to the package manager and won't be cleaned up upon package removal, for example. Such bypasses are not deemed acceptable by us.

The combination of these factors led us to the decision to remove the Deepin desktop completely from openSUSE Tumbleweed and from the future Leap 16.0 release. In openSUSE Leap 15.6 we will remove the offending deepin-feature-enable package only. It is a difficult decision given that the Deepin desktop has a considerable number of users. We firmly believe the Deepin packaging and security assessment in openSUSE needs a reboot, however, ideally involving new people that can help get the Deepin packages into shape, establish a relationship with Deepin upstream and keep an eye on bugfixes, thus avoiding fruitless follow-up reviews that just waste our time. In such a new setup we would be willing to have a look at all the sensitive Deepin components again one by one.

The announcement goes into detail about the bypass of openSUSE packaging policy and the history of security reviews of Deepin components. It also offers guidance on continuing to use Deepin Desktop on openSUSE.