Denver Gingerich of the Software Freedom Conservancy (SFC) has published an article on the impact of the ban on the sale of all new home routers not made in the United States issued by the Federal Communications Commission (FCC). The SFC, of course, is the organization behind the OpenWrt One router.

Since software updates to already-FCC-approved devices do not require a new FCC approval, it appears the FCC is trying to move beyond its usual authorization procedures to restrict what manufacturers are allowed to push to existing routers. However, the FCC notably does not restrict software changes made by owners of routers in the U.S. In particular, there is no indication that updates people make to their own routers, using software they have sourced themselves, would run afoul of any past or present FCC rule.

As a result, we do not believe that this new FCC decision affects whether and how people can run OpenWrt or other user-selected firmware updates on routers they have already purchased. Not only is this an important right in relation to our ownership and control of our own devices, it also ensures that people can keep their routers secure for far longer than the manufacturer may choose to provide security updates, by allowing them to install up-to-date community software that supports routers for 10, 15, or even more years after their initial release date, as OpenWrt does for many devices.

He also notes that, as the OpenWrt One is already FCC-approved, there should be no impact on its availability in the US. The SFC has asked the FCC for clarification and plans to provide updates when they receive a reply.

The kernel provides a number of ways for processes to communicate with each other, but they never quite seem to fit the bill for many users. There are currently a few proposals for interprocess communication (IPC) enhancements circulating on the mailing lists. The most straightforward one adds a new system call for POSIX message queues that enables the addition of new features. For those wanting an entirely new way to do interprocess communication, there is a proposal to add a new subsystem for that purpose to io_uring. Finally, the bus1 proposal has made a return after ten years.

Brian "bex" Exelbierd has published a blog post exploring follow-up questions raised by the recent debate about the use of the LLM-based review tool Sashiko in the memory-management subsystem. His main finding is that Sashiko reviews are bi-modal with regards to whether they contain reports about code not directly changed by the patch set — most do not, but the ones that do often have several such comments.

Hypothesis 1: Reviewers are getting told about bugs they didn't create. Sashiko's review protocol explicitly instructs the LLM to read surrounding code, not just the diff. That's good review practice — but it means the tool might flag pre-existing bugs in code the patch author merely touched, putting those problems in their inbox.

Hypothesis 2: The same pre-existing bugs surface repeatedly. If a known issue in a subsystem doesn't get fixed between review runs, every patch touching nearby code could trigger the same finding. That would create a steady drip of duplicate noise across the mailing list.

I pulled data from Sashiko's public API and tested both.

OpenSSH 10.3 has been released. Among the many changes in this release are a security fix to address late validation of metacharacters in user names, removal of bug compatibility for SSH implementations that do not support rekeying, and a fix to ensure that scp clears setuid/setgid bits from downloaded files when operating as root in legacy (-O) mode. See the release announcement for a full list of new features, bug fixes, and potentially incompatible changes.

Security updates have been issued by AlmaLinux (python3.11, python3.12, squid, and thunderbird), Debian (gst-plugins-bad1.0 and gst-plugins-ugly1.0), Fedora (bpfman, crun, gnome-remote-desktop, polkit, python3.14, rust-rustls-webpki, rust-sccache, rust-scx_layered, rust-scx_rustland, rust-scx_rusty, and scap-security-guide), Oracle (freerdp, gstreamer1-plugins-bad-free, gstreamer1-plugins-base, gstreamer1-plugins-good, and gstreamer1-plugins-ugly-free, kernel, libxslt, python3.11, python3.12, squid, and thunderbird), SUSE (389-ds, busybox, chromium, cosign, curl, docker-compose, exiv2, expat, firefox, freerdp, freerdp2, gstreamer-plugins-ugly, harfbuzz, heroic-games-launcher, ImageMagick, kea, keylime, libjxl, librsvg, libsodium, libsoup, net-snmp, net-tools, netty, nghttp2, poppler, postgresql13, postgresql16, postgresql17, postgresql18, protobuf, python-black, python-orjson, python-pyasn1, python-pyOpenSSL, python-tornado, python-tornado6, python311-nltk, thunderbird, tomcat10, tomcat11, vim, and xen), and Ubuntu (kernel, linux, linux-aws, linux-kvm, linux-lts-xenial, linux-raspi, linux-raspi, linux-raspi-realtime, rust-cargo-c, rust-tar, and undertow).

Greg Kroah-Hartman has released the 6.19.11, 6.18.21, 6.12.80, and 6.6.131 stable kernels, followed by a quick release of 6.6.132 with two patches reverted to address a problem building the rust core in 6.6.131. Each kernel contains important fixes; users are advised to upgrade.

Inside this week's LWN.net Weekly Edition:

• Front: LiteLLM compromise; systemd controversy; LLM kernel review; OpenBSD and vibe-coding; Rust trait-solver; Pandoc.
• Briefs: Rspamd 4.0.0; telnyx vulnerability; Fedora forge; SystemRescue 13.00; Servo 0.0.6; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.