Post Syndicated from jzb original https://lwn.net/Articles/1083754/

Michael Catanzaro, who has been managing GNOME security issue tracking since
November 2020, has written a blog post that details some changes in how he will
be managing GNOME vulnerability reports from now on due to an increase in
AI-generated security reports. He will be switching from a 90-day deadline for
disclosures to 30 days for issues reported on August 1, or later. “The
shorter deadline would probably work better for GNOME even if not for the
increase in AI-generated issue reports.“

He also has indicated that he will be stepping away from the task of managing
security issue tracking entirely by December 1, 2026, which means that there
will be a gap to fill:

Currently nobody else is tracking GNOME security issues. If you are an
experienced GNOME community member and you are interested in taking over this
work, let me know and I will help you get started. (Security tracking is not a
good task for newcomers.)

This may also be an opportunity to improve our tracking infrastructure. I use
a wiki
page, but this is fairly primitive and requires considerable manual
upkeep. It’s easy to forget to update the page when an issue report is closed,
for example. Ideally, we would replace the wiki with a proper web app that
dynamically updates based on the actual state of the issue.

Post Syndicated from jzb original https://lwn.net/Articles/1083708/

Security updates have been issued by Debian (kernel, libnfs, roundcube, and tiff), Fedora (antlr4-project, chromium, erlang, libseccomp, libtiff, log4cxx, mbedtls, node-exporter, opam, openssh, proftpd, python-asyncssh, python-django5, python-libcst, python-orjson, python-uv-build, ruby, rust-astral_async_zip, spoofdpi, uv, and yq), Mageia (bind, clamav, erlang, libidn, libreoffice, nmap, nodejs, perl-Bytes-Random-Secure, perl-Config-IniFiles, perl-CSS-Minifier-XS, perl-HTML-Parser, perl-Mojolicious, perl-String-Util, python-pydantic-settings, rsync, and upower), Oracle (.NET 10.0, .NET 8.0, .NET 9.0, bind, cockpit, cockpit-image-builder, coreutils, delve, dnsmasq, dovecot, expat, fence-agents, flatpak, frr, gdk-pixbuf2, giflib, glib2, go-fdo-client and go-fdo-server, golang-github-openprinting-ipp-usb, grafana, grafana-pcp, httpd, jq, kernel, keylime, krb5, libcap, libexif, libpng, libsndfile, libsolv, libsoup3, libtasn1, libtiff, libxslt, libyang, mariadb10.11, mod_http2, mod_md, opencryptoki, PackageKit, perl-Archive-Tar, perl-IO-Compress, poppler, postfix, postgresql-jdbc, python-urllib3, python3.14, python3.14-pip, python3.14-urllib3, qt6-qtdeclarative, rrdtool, rsync, ruby, ruby4.0, samba, skopeo, thunderbird, valkey, wireshark, xorg-x11-server-Xwayland, and yggdrasil-worker-package-manager), and SUSE (blender, chromium, containerized-data-importer1, cyrus-imapd, go1.26-openssl, gomuks, grafana, gstreamer-plugins-bad, kbfs, kubevirt1.8-container-disk, libxml2, lux, mariadb-connector-c, nginx, opam, openssl-3, oras, perl-DBI, php-composer2, python-django-haystack, python-paramiko, python-weasyprint, python311, python313-Pillow, python315, shibboleth-sp, system-user-zabbix, and wget).

Post Syndicated from jzb original https://lwn.net/Articles/1083392/

Collabora has published a blog
post about its work with Valve on Holo Core, which is a port of Arch Linux to
aarch64 to be used as the the operating system on Valve’s
64-bit Arm Steam Frame gaming system. Collabora has released the
sources,
binary
packages, and a container image for aarch64 devices. The post
describes some of the challenges in porting Arch Linux to a new
architecture, and what remains to be done:

Whilst the infrastructure developed to this point is capable of
building from first principles up until a point-in-time snapshot, the
next step is to build this into a system which can track Arch Linux as
it is developed. This work will serve as the basis of a
continuously-operating CI system capable of shadowing Arch Linux
itself. We will work with the upstream Arch Linux project to help Arch
with their efforts to port the distribution to aarch64 architecture
and work towards automated repeatable builds.

The post also includes instructions on how to create and test an
aarch64 build container on an x86_64 host, for users who would like to
follow along at home but lack a 64-bit Arm device.

Post Syndicated from jzb original https://lwn.net/Articles/1083388/

Security updates have been issued by AlmaLinux (cifs-utils, container-tools:rhel8, libreoffice, nodejs:24, perl-XML-LibXML, and python3.12), Fedora (ansible-collection-ansible-posix, firefox, freerdp, ImageMagick, mingw-glib2, perl-DBI, perl-HTTP-Date, rust-cargo-rpmstatus, and rust-opendal), Oracle (cifs-utils, gegl, gimp, git-lfs, go-toolset:ol8, hplip, kernel, libreoffice, maven:3.9, perl-XML-LibXML, python3, python3.12, python3.9, and uek-kernel), Red Hat (kernel, kernel-rt, and podman), Slackware (netatalk), SUSE (agama, aws-nitro-enclaves-binaryblobs-upstream, gimp, gpsd, grafana, hostapd, ImageMagick, jackson-databind, kernel, libssh2_org, nm-configurator, opennlp, perl-Mojolicious, python-Pillow, python-python-engineio, python-python-socketio, and tomcat11), and Ubuntu (ntfs-3g, python-authlib, ruby2.3, tar, and ubuntu-advantage-tools).

Post Syndicated from jzb original https://lwn.net/Articles/1083201/

Security updates have been issued by AlmaLinux (cups, git-lfs, kernel, libsolv, libxml2, python3.12, and python3.9), Debian (chromium, dhcpcd5, and ntfs-3g), Fedora (firefox, perl-Imager, python-bcrypt, python-tiktoken, roundcubemail, and xrdp), Mageia (openssl, poppler, python-mistune, and tmux), Oracle (389-ds-base, cups, git-lfs, glibc, host-metering, kernel, libsolv, libxml2, nginx:1.24, PackageKit, python-pillow, and qemu-kvm), Red Hat (buildah, containernetworking-plugins, and skopeo), SUSE (buildah, cosign, curl, distribution, dnsmasq, glib-networking, glibc, gnutls, gstreamer-plugins-bad, ImageMagick, kernel, podman, python-cryptography, python313-django-debug-toolbar, rekor, sccache, sssd, and yelp), and Ubuntu (dotnet8, dotnet10, libslirp, luajit, python-idna, sympa, and tomcat8).

Post Syndicated from jzb original https://lwn.net/Articles/1083076/

The SUSE Security Team Blog has a post
with an analysis of seunshare,
which is used by SELinux to confine untrusted programs. During a
review of version
3.10 of the program, the team identified two local
Denial-of-Service (DoS) vectors.

Since seunshare is supposed to run on SELinux-enabled systems, it
is important to understand what kind of privilege escalation can be
achieved when vulnerabilities are exploited in a setuid-root binary
like this. Many SELinux-enabled systems, such as Fedora and openSUSE,
ship with the “targeted” SELinux policy by default. This policy is
focused on confining well-known system services, but assigns an
unconfined SELinux context to interactive users by default to achieve
a balance between security and usability.

There is currently no domain transition from the unconfined domain
to the more restricted seunshare_t defined in the SELinux policy for
seunshare. This means the execution of seunshare continues in the
unconfined domain. Thus in the context of attacks carried out by
interactive users, the impact of the vulnerabilities below will be a
root-like privilege escalation despite the system running in SELinux
enforced mode.

See the post for the full write-up of the team’s discoveries and timeline. The
vulnerabilities have been fixed in version 3.11.

Post Syndicated from jzb original https://lwn.net/Articles/1083044/

Security updates have been issued by AlmaLinux (cifs-utils, corosync, cups, freerdp, git-lfs, go-fdo-client and go-fdo-server, go-toolset:rhel8, kernel, kernel-rt, libinput, libxml2, nginx:1.24, openssl, pacemaker, perl-DBI:1.641, php8.4, python-pillow, python3, and python3.12), Debian (grub2, libxfont, opam, and wolfssl), Fedora (freerdp, kernel, and prometheus), Mageia (imagemagick), Oracle (buildah, freerdp, gimp, kernel, nginx, openexr, openssl, perl-DBI, podman, vim, xorg-x11-server, and xorg-x11-server-Xwayland), Red Hat (python3.12), SUSE (afterburn, buildah, busybox, enc, freetype2-devel, go1.25, go1.25-openssl, go1.26-openssl, gosec, grafana, helm, krb5, kubernetes-old, libopenbabel8, libxml2, libxml2-16, nasm, openssl-3, patch, python-Authlib, python-mistune, python-soupsieve, python-sqlparse, python3-dulwich, python313-Pillow, rootlesskit, sbootutil-1, tomcat, and tomcat11), and Ubuntu (alsa-lib, dnsmasq, gnutls28, libheif, linux-aws, linux-fips, linux-lts-xenial, linux-gcp-5.15, linux-intel-iotg-5.15, linux-hwe-6.17, linux-raspi, mariadb, openvpn, python-httplib2, vim, and wget).

Post Syndicated from jzb original https://lwn.net/Articles/1080835/

Inside this week’s LWN.net Weekly Edition:

• Front: Cryptography API; Iomap explanation; Negative dentries; Faster RCUs and lockless allocation for BPF; Negative dentries; LLMs in memory-management code
• Briefs: Guix vulnerabilities; OpenSSH 10.4; trusted publishing; kernel archive; CalyxOS; Quotes; …
• Announcements: Newsletters, conferences, security updates, patches, and more.

Post Syndicated from jzb original https://lwn.net/Articles/1077427/

At the 2026 Linux Security Summit North America, Eric Biggers spoke about
some of the problems with the kernel’s cryptography framework, as well
as the recent progress in adding library APIs to allow developers to
use cryptographic functions without using the traditional crypto
API. He walked through a couple of examples to demonstrate the
frailty of the original API and showed how the new library API made
life easier for developers and kernel maintainers.

Post Syndicated from jzb original https://lwn.net/Articles/1081690/

William Woodruff, better known online as “yossarian”, has published
a blog post to make the case that users should not place their trust
in trusted
publishing:

Trusted Publishing is a mechanism for establishing trust between an
external machine identity (like a CI/CD workflow) and one or more
projects on a package index/registry. The “trust” in “Trusted
Publishing” refers to that trust relationship, and not to anything
else.

It is not, and cannot be, a signal for package trust or
quality. You cannot use it to determine whether a package is safe or
“good,” and PyPI consciously stymies attempts to misuse it for that
purpose by not rendering it as a “green checkmark” or anything else of
the sort.

Or as another framing: Trusted Publishing is just a form of
authentication. It doesn’t tell you anything other than that an upload
was authenticated, which all uploads to PyPI are.

LWN covered trusted
publishing in June.

Post Syndicated from jzb original https://lwn.net/Articles/1081644/

Security updates have been issued by AlmaLinux (nodejs22 and nodejs24), Fedora (clamav, hplip, kernel, kernel-headers, librabbitmq, mingw-expat, mir, perl-Imager, podman-tui, prometheus-podman-exporter, python-rpds-py, rust-ashpd, rust-busd, rust-gtk4-macros, rust-inferno, rust-quick-xml, rust-reqsign-aws-v4, rust-wayland-scanner, and sandogasa), Oracle (container-tools:rhel8, kernel, mariadb:10.11, mariadb:11.8, nginx, perl:5.32, php, php:7.4, rrdtool, ruby:2.5, ruby:3.3, ruby:4.0, and uek-kernel), Red Hat (kernel, opentelemetry-collector, and python-urllib3), Slackware (c-ares and openssh), SUSE (bind, chromedriver, cryptsetup, s390-tools, dnsmasq, jackson-annotations, jackson-core, jackson-databind, lcms2, pacemaker, perl-Cpanel-JSON-XS, perl-Crypt-SaltedHash, postfix, and python-mistune), and Ubuntu (gnutls28, gzip, openssh, php7.0, python-parsl, python3.10, python3.12, python3.14, request-tracker5, socat, sogo, and tar).

Post Syndicated from jzb original https://lwn.net/Articles/1081536/

OpenSSH 10.4 has been released. In addition to a number of security
and bug fixes, there are a few notable changes; this release adds
experimental support for a composite post-quantum signature scheme
combining ML-DSA 44 and Ed25519 as described in this
IETF draft. With 10.4, if OpenSSH is compiled with sandbox support
it will fail on Linux systems that have not enabled SECCOMP
or NO_NEW_PRIVS; prior to this release, sshd would log an error
but continue operation. See the release notes for
a full list of changes.

Post Syndicated from jzb original https://lwn.net/Articles/1081495/

Security updates have been issued by AlmaLinux (container-tools:rhel8, grafana, grafana-pcp, kernel, ruby:2.5, and ruby:3.3), Debian (bird3, chromium, kernel, linux-6.1, mediawiki, nginx, openvpn, php-phpseclib, php8.2, php8.4, and sympa), Fedora (7zip, buildah, chromium, clamav, freerdp, leptonica, mariadb10.11, mariadb11.8, nextcloud, nsd, openqa, openvpn, os-autoinst, pdns, pdns-recursor, perl-Crypt-ScryptKDF, podman, python-jupyter-server, and python-streamlink), Mageia (mariadb and yt-dlp), Slackware (libevent, libseccomp, mozilla, mutt, and php82), SUSE (apache2, containerd, dnsmasq, docker, dracut, firewalld-legacy, gimp, glibc, golang-github-docker-libnetwork, google-guest-agent, gstreamer-plugins-bad, helm, kernel, kernel-devel, keybase-client, kitty, krb5, libarchive, libnfs, libslirp, nilfs-utils, openCryptoki, openQA, openssl-3, pacemaker, pcr-oracle, perl-DBI, perl-List-SomeUtils-XS, podman, python-pip, python-pydata-sphinx-theme, python-tornado6, python3-lxml, python311-mistune, python313-joserfc, rmt-server, sg3_utils, systemd, tracker-miners, and xdg-dbus-proxy), and Ubuntu (cifs-utils, linux-nvidia, linux-nvidia-6.17, linux-raspi-realtime, and ncurses).

Post Syndicated from jzb original https://lwn.net/Articles/1081230/

Greg Kroah-Hartman has announced the release of the 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260 stable kernels. Several kernels
in this batch include a
fix for a vulnerability introduced in the 6.0 kernel in IPv6 (CVE-2026-53362),
which could
allow an attacker to escape a container and gain root access.

There is also a
fix for a use-after-free bug in KVM (CVE-2026-53359)
that was introduced in the 2.6.36 kernel. As usual, each stable kernel includes
a number of fixes throughout the tree. Users are advised to
upgrade.

Post Syndicated from jzb original https://lwn.net/Articles/1081199/

The GNU Guix project has announced
three vulnerabilities in the guix substitute utility as well
as a fourth that affects the guix pull and guix
time-machine commands. The impact of the vulnerabilities ranges from remote privilege
escalation to local disclosure of sensitive files.

The remote exploitation of guix substitute only requires that the
vulnerable system attempt to download a binary substitute. Any
configured substitute server, including ones discovered using
guix-daemon‘s --discover option, can exploit this, and so can a
man-in-the-middle (MITM), regardless of whether https is used in the
substitute server urls.

The local exploitation of guix substitute only requires
the ability to connect to guix-daemon’s socket, which by default any
user can do.

Separately, another security issue (CVE ID pending) was identified
in guix pull and guix time-machine, which enables anyone who can
control the channels file used by these commands to cause a file to be
created or overwritten wherever the user running the command in
question has permission to create them.

The project is recommending that all users upgrade guix
and guix-daemon immediately. See the announcement for
instructions, how to test for the vulnerabilities, the disclosure
timeline, and more.

Post Syndicated from jzb original https://lwn.net/Articles/1081187/

Security updates have been issued by AlmaLinux (389-ds-base, bind9.18, evince, fence-agents, freerdp, frr, frr10, gimp, gnutls, hplip, jmc, mariadb:11.8, mysql:8.4, php:7.4, postgresql-jdbc, postgresql:15, postgresql:16, valkey, xorg-x11-server, and xorg-x11-server-Xwayland), Debian (fastnetmon), Fedora (7zip, apptainer, cpp-httplib, mysql8.4, and nmap), Oracle (freerdp, giflib, glib2, glibc, kernel, libreoffice, libvirt, mariadb:10.11, postgresql, python3.11, python3.12, rrdtool, and thunderbird), Red Hat (buildah, podman, and skopeo), SUSE (alloy, apache2, buildah, c3p0, containerd, crun, cups, dhcpcd, dnsmasq, docker-stable, dracut, editorconfig-core-c, ffmpeg-7, fontforge, google-guest-agent, google-osconfig-agent, graphicsmagick, gstreamer-plugins-bad, gstreamer-plugins-good, helm, jackson-annotations, jackson-core, jackson-databind, jline3, kernel, kubectl-cnpg, lcms2, libslirp, libssh2_org, libxreaderdocument3, openbabel, openssl-3, pacemaker, perl-CGI-Session, perl-list-someutils-xs, python-lxml, python-tornado, python-tornado6, python3-onionshare, python311-python-engineio, sg3_utils, thunderbird, transmission, and trivy), and Ubuntu (cifs-utils, kernel, libvncserver, linux-aws-6.8, linux-gcp-6.8, linux-gke, linux-gkeop, linux-ibm-6.8, linux-nvidia-lowlatency, linux-oracle-6.8, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia-tegra, linux-oracle-5.15, linux-raspi, linux-xilinx, nghttp2, nginx, perl, and vim).

Post Syndicated from jzb original https://lwn.net/Articles/1081038/

In August 2025, the CalyxOS privacy-focused
Android distribution announced
that it was pausing all releases while it reworked its
release process, security protocols, and changed its signing keys
following the departure of one of its founders. The project has now announced
that it is “officially back from the hiatus” with the
7.2.2.0 release.

CalyxOS 7.2.2.0 is signed by us using a new
HSM-based, open-source signing solution we designed to enhance the
security of the entire signing process, ensure redundancy, and remove
single points of failure. You can verify CalyxOS 7.2.2.0 and future
builds following these
instructions. For anyone who is interested, the security audit
report of the HSM provisioning ceremony script can be found here.

In addition, we also went through significant infrastructure
improvements. In particular, we have set up a cleaner server structure
to streamline each release. In response to Google’s less frequent AOSP
source code releases, our team developed scripts to reduce the
overhead in applying monthly patches and updates. Please keep in mind,
additional manual steps are still needed to compensate for AOSP
changes, such as requesting and storing kernel sources with each
update. Currently, our lead engineer is continuing the maintenance of
the base device trees for both LineageOS and CalyxOS to bridge the gap
created by the absence of Google Pixel device trees.

Post Syndicated from jzb original https://lwn.net/Articles/1081015/

A few astute observers have noticed that some
content on kernel.org had disappeared and were understandably
concerned. Konstantin Ryabitsev has provided an update via
social.kernel.org:

There was an unfortunate error while changing the kernel.org
primary/secondary mirroring infrastructure, which resulted in the /pub
tree suddenly becoming empty. No data was lost, just public mirror
copies. Everything is now being restored, but deletes are fast and
restores are slow, so thank you for your patience!

The incident is
being tracked on the Linux Foundation’s IT status page.

Post Syndicated from jzb original https://lwn.net/Articles/1081012/

We were made aware today of an email sent to a reader that was
spoofed to appear to be from LWN. The message claimed, among other
things, that we were providing personal information about the reader
to another site user. As is explained in our privacy policy we do not,
and would not, provide such information.

If any other readers have received an odd message from LWN, it is
an attempt at a hoax; if in doubt, please check the DKIM header of the
email. Any email that does come from LWN will have a proper DKIM
signature in its headers.

If you receive such a message, please feel free to send it to us,
with its headers intact. But to reiterate, we are not providing any
user information upon request, nor banning any accounts. We hope this
will not be a recurring problem.

Post Syndicated from jzb original https://lwn.net/Articles/1081013/

Aoife Moloney has, on behalf of the Fedora Council, posted an
announcement that the Fedora Council is “proposing we pause the
Community Initiatives process as an official project process”
because it has decided the current process is ineffective. It is also
closing discussion regarding the AI developer desktop
initiative covered by LWN in May.

The Fedora Objectives/Initiatives framework was never intended as a
mandatory prerequisite to do the work in Fedora. It supposed to help
by focusing the community on a certain work when needed, not to decide
what is allowed. The AI developer desktop initiative proposal
highlighted that the Community Initiatives process has failed to serve
as a good framework in Fedora where new ideas can surface, receive
respectful feedback, and gain Council support for work that fits the
project’s present and/or future. This is something that the Council
must address.

As a first step, we would like to halt the community initiative
process immediately. Existing initiatives in flight (Fedora Forge,
Atomic, and Fedora Docs 2026) will continue with full Council
backing. Their underlying work will be completed as planned in their
current timeboxed state, though the administrative framework around
them may evolve.
As a second step, we would like to work out a new mechanism to allow
Council to set strategic direction in an open, transparent way that
more intentionally includes the community voice. We recognise that we
have to be better at being more open in our discussions and decision
making.

The council is considering the “sandbox” proposal as an
alternative or supplement to a process that replaces the Community
Initiatives.