The It's FOSS blog has news about the Linux Vendor Firmware Service, which gives hardware vendors a secure portal to upload firmware updates "which can then be downloaded and installed by users through clients such as GNOME Software or fwupdmgr." (Originally developed in 2015 by GNOME maintainer Richard Hughes...) The issue, however, obviously, had been funding with the largest contributors being the usual suspects, Framework and Open Source Framework Foundation, at $10K a year. Recently, however, Lenovo and Dell joined suite as Premier sponsors, which is the highest tier at $100K a year each, making the project more sustainable and manageable.

These companies contributing makes a lot of sense, considering they are two of the bigger computer companies which offer Linux by default in some cases, especially with Lenovo's ThinkPads being the Linux users' favorite for decades. And now... HP has followed suit as a Premier sponsor, also providing $100K a year, right alongside Dell and Lenovo...

The question still remains, however, where are the other vendors? What are they waiting for... This major move by these three companies should not only be seen as a sign of relief and wider acceptance of the usage of Linux, but as a beacon for other vendors to follow, who ought to make their hardware more accessible to the open-source community.

Linus Torvalds spoke this week at the Linux Foundation's Open Source Summit North America, reports ZDNet — and described how AI is impacting Linux kernel development: "In the last six months, we've seen a lot more commits," Torvalds noted, estimating that "the last two releases, it's been about 20% more commits than we had in the previous releases over many years.... The real change that happened in the last six months was that the AI tools actually got good enough for a lot of people... we're seeing a definite uptick in just development on pretty much all fronts...."

On the positive side, he framed AI-discovered bugs as "short-term pain" with long-term benefits: "When AI finds a bug in any source code... long term is you found a bug, we fixed it, that the end result is better for it." After all, he continued, "I think finding bugs is great, because the real problem is all the bugs you didn't find..." For small teams or solo maintainers, he said, flood-style AI bug reports can cause real burnout, especially when "it's a bug report, and when you ask for more information, the person has done a drive-by and doesn't even answer your questions anymore."
The AI news site Techstrong notes this quote from Torvalds. "I have a love-hate relationship with AI. I actually really like it from a technical angle, I love the tools, I find it very useful and interesting, but it is definitely causing pain points." The chief challenge with AI is that it forces people to change how they work, he found. People get into a rut, and AI challenges their norm. The Linux security mailing list got the brunt of this new wave of AI-generated commits. Not all bugs are security issues, but when "people think that when they find a bug with AI, the first reaction seems to sometimes be let's send it to the security list, because this may have security implications," Torvalds said. As a result, the security list — watched over by a small group of maintainers — was overrun by duplicate entries...

The Linux project learned to manage the bug influx with a set number of tools to sort out and deprioritize the obvious drive-by reports (ones where the person submitting the report won't even answer any questions). One tool, Sashiko, reviews all the patches submitted on the mailing list. "Sometimes the review is not great, but quite often it finds issues and it asks questions and says, 'Hey, what about this issue?'" he said.
Linux also updated their documentation, partly just to address "an uptick in bug and security reports from discoveries made in full or in part with AI."

Long-time Slashdot reader Sun writes: AMD has announced a change to the way they are licensing Vivado, their FPGA development tool... Hidden between the lines of the announcement [of a new model starting with the 2026.1 release] is the change to the free of charge tier. AMD is adding more devices to be supported in this tier, which is supposedly the carrot. The stick, however, is the removal of certain debug features.

The thing that's likely to hit the hobbist community the worst, however, is that the free tier will now not be available on Linux.

AMD are saying that old licenses are still in effect, so it appears that if you hurry to install Vivado now, you'd still be able to use it moving forward. It is not clear, however, whether it'll still be possible to install Vivado 2025.2 after Vivado 2026.1 becomes available.
"Almost all our surveys show... close to 70% of the customers are still using Windows," explained AMD senior product application engineer Anatoli Curran on the tool's support forum. "Vivado ML Standard Edition v2025.2 is going to be officially supported (I mean if there are any bugs found, these can be fixed) until v2026.3 release... Any release older than the current 3 released versions of Vivado then becomes unsupported (meaning no bugs will be fixed with Vivado Standard Edition v2025.2 after Vivado v2026.3).

"However, users can continue using V2025.2 forever, if they wish to do so... Also, Vivado ML Standard Edition v2025.2 is license-free... Users only need to obtain and use any IP Core related licenses, or Vivado Model Composer (for SysGen)."

Qualys's Threat Research Unit (TRU) has discovered and published a logic flaw in Linux kernel "that permits an unprivileged local user to disclose sensitive files and execute arbitrary commands as root on default installations of several major distributions." Friday their blog pointed out "The bug has resided in mainline Linux since November 2016 (v4.10-rc1)."

"Upstream patches and distribution updates are already available." Working exploits are circulating publicly, and administrators should apply vendor kernel updates without delay. During ongoing research into Linux kernel privilege boundaries, TRU identified a narrow window in which a privileged process that is dropping its credentials remains reachable through ptrace-family operations even though its dumpable flag should have closed that path. By pairing this window with the pidfd_getfd() syscall (added in v5.6-rc1, January 2020), an attacker can capture open file descriptors and authenticated inter-process channels from a dying privileged process and re-use them under their own uid. The primitive is reliable and turns any local shell into a path to root or to sensitive credential material [including host private keys under /etc/ssh ]

CVE-2026-46333 is local-only, but the impact is severe... Any unprivileged shell on a vulnerable host is enough to read /etc/shadow, exfiltrate SSH host private keys, or execute arbitrary commands as root through hijacked dbus connections to systemd. In practice, the distinction between an unprivileged foothold and full host compromise collapses: a phished developer account, a constrained CI runner, a low-privilege service account, or a shared multi-tenant host all become direct paths to root. With the vulnerable code shipping in mainline kernels since v4.10-rc1 (November 2016), the historical exposure spans nine years of enterprise fleets, cloud images, and container hosts.

Qualys followed responsible disclosure throughout. Qualys reported the vulnerability privately to the upstream Linux kernel security contact on 2026-05-11. Over the following three days the kernel security team developed and reviewed the fix, CVE-2026-46333 was assigned, and the patch was committed publicly on 2026-05-14. We then engaged the linux-distros mailing list, the standard pre-disclosure channel for downstream coordination. A short time later, an independent exploit derived from the public kernel commit appeared.... Qualys is releasing the complete advisory today because the underlying technique is novel, the public picture is now incomplete and uneven, and independent researchers have already achieved local root and published exploit material. Doing so gives defenders, detection engineers, and downstream maintainers a single authoritative reference for the flaw, the race against do_exit(), the role of pidfd_getfd(), and the four exploitation case studies.

BrianFagioli writes: Flipper Devices has finally revealed Flipper One, a Linux-powered cyberdeck that sounds less like a gadget and more like an attempt to rebuild portable ARM computing from the ground up. Unlike Flipper Zero, which focuses on offline protocols like RFID and Sub-1 GHz radio, Flipper One is all about networking, modular hardware, SDR experimentation, local AI, and upstream Linux kernel support. The company says it wants to build "the most open and best-documented ARM computer in the world," complete with zero vendor BSP dependency and as few binary blobs as possible. That alone is enough to get Linux folks paying attention.

The hardware itself is loaded with nerd bait: dual Gigabit Ethernet, Wi-Fi 6E, M.2 expansion for SSDs and 5G modems, GPIO add-ons, HDMI 2.1, and a dual-processor architecture pairing a Rockchip RK3576 with a Raspberry Pi RP2350 microcontroller. Flipper Devices is even developing its own small-screen Linux UI framework because squeezing KDE onto tiny touchscreens is miserable. The company openly admits the project is financially and technically terrifying, which honestly makes this announcement feel more believable than most startup hardware pitches. Whether Flipper One succeeds or not, it is one of the most ambitious Linux hardware projects in years.

Red Hat has released RHEL 10.2 and 9.8 with new AI-assisted command-line tools. The releases also add updated developer toolchains such as Go 1.26, LLVM 21, Rust 1.92, Python 3.14, and PHP 8.4. Phoronix reports: Red Hat Enterprise Linux has introduced the goose command for power users. Goose is an optional CLI AI assistance with model context protocol (MCP) integration. There is also improved visual output via color output enhancements. As for their rationale with the new AI integration: "The business value: Faster problem resolution, and a quicker path for new administrators to become proficient. This translates into higher developer productivity and accelerated project timelines."

A long-running lawsuit over Vizio's Linux-based smart TV software is headed to trial in August, with the Software Freedom Conservancy arguing that GPL rules require Vizio to release complete source code owners could use to modify, maintain, or strip ads and tracking from their TVs. Ars Technica reports: The outcome could reverberate across the industry. Because many of today's popular smart TV operating systems are Linux-based, the case may help determine how much control many owners have over their sets. Access to the full code would allow users to make meaningful changes to how their TVs work, including limiting ads or deactivating automatic content recognition.

[...] The Software Freedom Conservancy argues it has the right to Vizio OS's source code because it owns several Vizio TVs and because the operating system is based on Ubuntu, a Linux distribution. (SFC employees bought seven Vizio TVs from 2018 to 2021 after getting complaints about Vizio not sharing its TVs' source code, according to the complaint.) In general, the Linux kernel is provided under the terms of GPLv2, as noted by kernel.org, which is run by the Linux Kernel Organization.

SFC's lawsuit alleges that Vizio breached GPLv2 and LGPLv2.1 by failing to make available the complete source code for Vizio OS. The case is currently in the Orange County Superior Court of the State of California. The lawsuit targets Vizio specifically, but the impact could extend to other Linux-based smart TV OSes such as LG's webOS, Samsung's Tizen, and Roku's Roku OS. "We expect all companies who distribute Linux and other software using right-to-repair agreements like the GPL in their products would comply with these agreements," Denver Gingerich, the director of compliance at SFC, told Ars. [...] SFC expects a ruling within three to six months of the conclusion of the trial, which is currently scheduled for August 10.

Microsoft is turning Azure Linux into a general-purpose, Fedora-based cloud distribution available to all Azure customers, while also productizing Flatcar as Azure Container Linux for immutable container hosts. "When Microsoft joined the Linux Foundation, there was this big conspiracy theory that somehow the Linux Foundation was undermining open source in partnership with Microsoft, and now you announce that you're shipping a Linux distribution," Jim Zemlin, the Linux Foundation's CEO, said in response to Microsoft's surprise announcement. "That's amazing." ZDNet reports: Until now, [Lachlan Everson, Microsoft's Principal Program Manager on Azure's open-source team] noted, "we had Azure Linux only available to third-party customers through AKS specifically, and that was Azure Linux 3.0." Going forward, this will be ACL. Everson emphasized that Azure Linux 4.0 is the culmination of years of internal usage and the evolution of the earlier Mariner distribution. "So we've been running Azure Linux for many years internally, and we got through to 3.0, and we only allowed it on as a container host on AKS. What we've done is make it a general-purpose, so this is all the learnings that we've had in the heritage of Mariner."

Under the hood, Azure Linux 4.0 is based on Fedora Linux and is delivered as an open distribution on GitHub. This code is available now. Yes, Red Hat knows that Microsoft has done this. Everson continued, "So, we made a decision to use Fedora as an upstream, so it's using RPMs in the Fedora ecosystem. Microsoft curates the packages and the supply chain to fit Azure's cloud platform." Microsoft also created "it to be purpose-built for Azure, which integrates vertically into all of our infrastructure to give you the best Azure Linux experience on Azure." While Azure Linux will ship as a VM image, Microsoft is already preparing a developer-friendly path onto Windows desktops: "And as of today, we have it as a VM image for your VM host on Azure. We're going to announce WSL images as well."

While developers will be able to run Azure Linux locally through WSL, Microsoft is not positioning it as a traditional desktop Linux. Asked whether he could run it on his laptop, Everson said: "I will be able to run it on my laptop, or what have you. Yes, on Windows 11." However, when pressed about a desktop experience, Everson was clear that there are "no plans" for a graphical environment. "It's optimized for server-side in the cloud," he said, adding that even on a developer machine, users should expect a lean environment. "Minimal packages, yeah. The idea is that we offer you a consistent experience to do your development on your machine, and that you can take your workloads as you develop them on your machine and run them with VS Code. You can run your applications on that, and know that the platform is the same that you're running on the cloud, so that you have that kind of consistency between environments."

Flatcar itself remains the upstream project, but Microsoft is packaging it for Azure customers. Everson described Flatcar as "purpose-built, immutable, secure by default, production-ready operating system, and Azure Container Linux is the productization of that, but we're still investing in the upstream Flatcar ecosystem and pulling that downstream into a productized exterior experience just for container workloads, so it's a container hosting in AKS." To underscore the immutable model, he added that "Everything's baked in, so there is no package manager. We bake the bits into the immutable, and they're in the immutable version. So Azure Container Linux is the immutable version. So you shouldn't be changing any system packages or any application packages. Anything that you need to change is customer workloads run in containers."

Today Linus Torvalds announced another Linux release candidate on the kernel mailing list. But he also highlighted "documentation updates" to address a new problem.

"The continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools." (The new documentation says the security team has found "bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day.") TORVALDS: People spend all their time just forwarding things to the right people or saying "that was already fixed a week/month ago" and pointing to the public discussion.

Which is all entirely pointless churn, and we're making it clear that AI-detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved — and only makes that duplication worse because the reporters can't even see each other's reports.

AI tools are great, but only if they actually help, rather than cause unnecessary pain and pointless make-believe work. Feel free to use them, but use them in a way that is productive and makes for a better experience.

The documentation may be a bit less blunt than I am, but that's the core gist of it.
The new documentation offers this overview. "It turns out that the majority of the bugs reported via the security team are just regular bugs that have been improperly qualified as security bugs due to a lack of awareness of the Linux kernel's threat model."

"So just to make it really clear," Torvalds said at the end of his post. "If you found a bug using AI tools, the chances are somebody else found it too.

"If you actually want to add value, read the documentation, create a patch too, and add some real value on *top* of what the AI did. Don't be the drive-by 'send a random report with no real understanding' kind of person. Ok?"

Long-time Slashdot reader internet-redstar shares an interestging response to "the recent wave of Linux kernel privilege escalation vulnerabilities like 'Copy Fail' and 'Dirty Frag'": Belgian Linux sysadmin and Tesla Hacker "Jasper Nuyens" got tired of the idea of manually blacklisting dozens or even hundreds of obscure kernel modules across large fleets of Linux systems in the near future. So he wrote ModuleJail, a GPLv3 shell script that scans a running Linux system and automatically blacklists currently unused kernel modules, reducing kernel attack surface without requiring a reboot. The idea is simple: many modern Linux privilege escalation bugs target obscure or rarely used kernel functionality that is still enabled by default on servers that do not actually need it. ModuleJail works across major distributions including Debian, Ubuntu, RHEL, Fedora, AlmaLinux and Arch Linux, generating 1 modprobe blacklist rules file while preserving commonly-used modules.

Nuyens argues that the increasing speed of AI-assisted vulnerability discovery will likely turn kernel hardening and attack surface reduction into a much bigger operational priority for sysadmins over the next few weeks and months.

The blog It's FOSS has an update on the Fedora AI Developer Desktop Initiative, a proposed platform for AI/machine learning workloads on Fedora. It's now been blocked "after two Fedora Council members retracted their earlier approval votes." The initiative was proposed by Red Hat engineer Gordon Messmer, aiming to deliver an Atomic Desktop with accelerated AI workload support, covering developer tools, hardware enablement, and building a community around AI on Fedora... At the May 6 council meeting, the members unanimously voted to approve this new initiative. After which a short, lazy consensus window was left open until May 8 to accommodate absent members, after which the decision was to be ratified.

But that last bit never happened, as council member Justin Wheeler (Jflory7) was the first person to change their vote to -1... ["While I strongly support leveraging AI to establish Fedora as a leading platform, completely rearchitecting our kernel strategy is a massive structural shift. It requires explicit alignment with our legal and engineering stakeholders before we commit the project to this path."] Following that, fellow council member Miro HronÄok (churchyard) put in his -1, saying that he had originally assumed the proposal was purely additive and therefore uncontroversial. But seeing the community's response, he realized that he was mistaken about that. As an elected representative, he felt the need to reflect on this major proposal before signing it off.

Over 180 replies have piled up in the proposal's discussion thread, with many well-known Fedora contributors pushing back on things like kernel policy, proprietary software, and project identity. Hans de Goede from the packaging team called out the proposal's emphasis on CUDA support as going against Fedora's foundational commitment to free software, arguing that open alternatives like AMD's ROCm and Intel's oneAPI should be the focus instead.

The Linux 7.1 kernel has added new documentation clarifying what qualifies as a security bug and how AI-assisted vulnerability reports should be handled. Phoronix reports: Stemming from the recent influx of security bugs to the Linux kernel as well as an uptick in bug and security reports from discoveries made in full or in part with AI, additional documentation was warranted. Longtime Linux developer Willy Tarreau took to authoring the additional documentation around kernel bugs. To summarize (since the documentation is a bit too lengthy for a Slashdot story), the AI-assisted vulnerability reports should "be treated as public" because such findings "systematically surface simultaneously across multiple researchers, often on the same day." It adds that reporters should avoid posting a reproducer openly, instead "just mention that one is available" and provide it privately if maintainers request it. The guidance also tells AI-assisted reporters to keep submissions concise and plain-text, focus on verifiable impact rather than speculative consequences, include a thoroughly tested reproducer, and, where possible, propose and test a fix.

As for what qualifies as a security bug, the documentation says the private security list is for "urgent bugs that grant an attacker a capability they are not supposed to have on a correctly configured production system" and are easy to exploit, creating an imminent threat to many users. Reporters are told to consider whether the issue "actually crosses a trust boundary," since many bugs submitted privately are really ordinary defects that belong in the normal public reporting process.

All the new documentation can be read via this commit.

BrianFagioli writes: SOLAI has launched the Solode Neo, a $399 Linux-based mini PC designed for always-on AI agents, browser automation, and persistent developer workflows. The compact system ships with an Intel N150 processor, 12GB LPDDR5 memory, 128GB SSD storage, Gigabit Ethernet, WiFi, Bluetooth, and a Linux-based operating system called Solode AI OS. The company says the device supports frameworks and tools including Claude Code, OpenAI Codex, Gemini CLI, and Hermes, while emphasizing local control, automation, and privacy-focused workflows running directly from a home network.

While SOLAI markets the Solode Neo as an "AI computer," the hardware itself appears aimed more at lightweight automation and cloud-assisted agent tasks than heavy local inference. The low-power Intel N150 should be sufficient for browser automation, scheduling, monitoring, containers, and smaller AI workloads, but the system is unlikely to compete with higher-end local AI hardware designed for running larger models offline. Even so, the idea of a dedicated low-power Linux appliance for persistent AI and automation tasks may appeal to homelab users and self-hosting enthusiasts looking for a simpler alternative to building their own always-on workflow box from scratch.

A new Linux local privilege escalation flaw called Fragnesia has been disclosed as a Dirty Frag-like vulnerability, allowing arbitrary byte writes into the kernel page cache of read-only files through a separate ESP/XFRM logic bug. Phoronix reports: Proof of concept code for Fragnesia is already out there. There is a two-line patch for addressing the issue within the Linux kernel's skbuff.c code. That patch hasn't yet been mainlined or picked up by any mainline kernel releases but presumably will be in short order for addressing this local privilege escalation issue. More details can be found here.

Linux 7.1 started phasing out support for Intel's 37-year-old i486 processor. Linux 7.2 removed drivers for the old AMD Elan 32-bit systems on a chip.

And now some i586 and i686 class processors are being removed, reports Phoronix: Supporting those vintage GPUs without the Time Stamp Counter "TSC" instruction are becoming a burden... TSC-capable Intel Pentium processors and the likes will still be supported with this just being for TSC-less i586/i686 CPUs. Among the CPUs impacted by this latest change is the AMD K5 as well as various Cyrix processor models. The K5 was AMD's first entirely in-house designed processor that was first introduced in 1996 to counter the Intel Pentium CPU.
TSC "support can now be assumed as a boot requirement for modern Linux," the article points out, which will allow the removal of various non-TSC code paths from the Linux kernel's x86 code.

Tom's Hardware remembers the K5 "wasn't a very popular processor as it arrived late, then offered lackluster performance in the competitive environment it joined." Launch SKUs in 1996 were limited to clocks from 75 MHz to 133 MHz, and, due to being late, Intel's Pentium line was already faster. AMD still managed to get an edge on the Cyrix 6x86, though.