The Linux kernel is approaching a staggering 2,000 CVEs fixed per release, up from roughly 500 through much of the Linux 6.x era, as AI and large language models increasingly scour the operating system’s enormous codebase for vulnerabilities. According to an August 28 Phoronix report, Linux stable maintainer Greg Kroah-Hartman revealed the trend in a slide teasing an upcoming presentation at Kernel Recipes 2026, showing CVE counts jumping above 1,000 with Linux 7.0 and exceeding 1,500 with Linux 7.2. If the current trajectory continues, Linux 7.3 could push the figure beyond 2,000.

Rather than a change in Linux’s security or a rise in vulnerabilities, the spike is mainly due to “detectives” using AI tools to scour the Linux kernel source tree, which has grown to over 40 million lines over 35 years of Linux’s existence. These tools can examine countless obscure sections humans may rarely revisit, occasionally finding genuine defects; Linux CVE records this year already explicitly credit AI-assisted static analysis with finding vulnerabilities subsequently confirmed by Intel Product Security. However, many of the findings have been low-priority vulnerabilities — often within obscure driver code — questionable patches, and outright hallucinations, leaving human maintainers to separate useful work from noise.

This problem already constitutes a nuisance for kernel teams that have to fix these issues. In the Linux 7.3 networking pull request, maintainer Jakub Kicinski estimated that between one-third and one-half of the 648 net-next patches handled during the cycle appeared to be low-priority fixes, clean-ups, or clarifications driven by AI. "We are completely overwhelmed,” Kicinski wrote.

The issue has also led Linux maintainers to question whether decades-old drivers are worth keeping alive. In April, developer Andrew Lunn proposed removing nearly 28,000 lines of legacy networking code covering old ISA and PCMCIA-era hardware. While these drivers historically required little attention because they barely had any users, the AI and fuzzing tools started finding defects that maintainers were obligated to investigate and fix, regardless of whether anyone actually runs the hardware.

Linux 7.3 is removing old SGI and IBM driver code, while other ancient components have also been retired as maintainers reassess whether their compatibility value justifies their new maintenance cost. The FreeVxFS filesystem driver, for example, was removed after its maintainer said the decades-old compatibility code now largely served as fodder for automated bug checkers.

Now, the kernel community is not simply rejecting AI; Kroah-Hartman himself has successfully used locally-running AI-assisted fuzzing tools to uncover kernel bugs. The bone of contention is unverified AI output dumped onto humans for validation. Kroah-Hartman recently barred LLM-generated patches from the kernel’s staging subsystem except for legitimate security fixes, while updated kernel guidance warns that AI-generated reports submitted without human verification can waste maintainer time.

The team has also increasingly had to fight AI with AI. It has now secured access to multiple frontier models to help review patches and filter out hallucinated results, and is considering pushing more routine administrative work onto LLMs in subsequent development cycles. Kroah-Hartman is expected to discuss the trend further at Kernel Recipes, which is slated to run from September 21 to 23 in Paris. Linux 7.3 itself has already entered testing, with Linus Torvalds releasing Linux 7.3-rc1 on August 30 after closing its two-week merge window.

California’s legislature has passed Assembly Bill 1856, exempting open-source operating systems from the State’s Digital Age Assurance Act months before the law is due to take effect on January 1, 2027. The Senate amended the Bill on August 21 before passing it on the 26th in a 39-0 vote, with the Assembly then accepting these changes in a concurrence vote the following day. The amendment ends almost a year of uncertainty surrounding whether Linux distributions and SteamOS would be forced to collect user age data during account setup alongside Windows, macOS, iOS, and Android. AB 1856 has now been sent to Governor Gavin Newsom, who signed the original act into law last October.

These amendments redefine the term “operating system provider” to exclude any person or entity that distributes an OS or application “under license terms that permit a recipient to copy, redistribute, and modify the software.” Any software distributed under the GPL, MIT, BSD, and Apache licenses satisfies that test, which removes the likes of Debian, Fedora, Ubuntu, Arch, and the BSD family from AB 1856’s scope.

A second exclusion removes software components that aren’t “offered to consumers as a stand-alone executable application through a covered application store” from the law’s definition of an application, covering libraries and dependencies distributed through package managers like apt and pacman. AB 1856 doesn’t explicitly say that repos aren’t app stores, but a store’s main obligation under the law is to request an age signal from the user’s OS provider and pass it to developers; an exempt open-source OS produces no signal. A third carve-out excludes storefronts distributing extensions or add-ons that run exclusively inside a host application, which takes browser extension stores out of scope.

The amendments to AB 1856 also remove the original definition of “user,” which read, “a child that is the primary user of a device,” and technically classified every device owner in California as a child. The law’s signaling framework depends on adults declaring their age on account setup, so their devices get flagged as 18 and over, but under that definition nobody could ever be flagged as an adult.

In addition, lawmakers inserted a new provision prohibiting anyone from requesting an age signal from an OS provider or app store unless required by law. That closes off potential abuse of the age API that could have led to it being used as a general-purpose data collection channel even when age verification wasn’t required. Platforms and developers also gain a good-faith safe harbor against erroneous signals, protecting them from liability when age-gating signals are inaccurate.

Windows, macOS, iOS, and Android remain fully in scope, with age collection required at account setup from January 1, 2027. A later July 1, 2027, deadline applies to devices set up before January 1. Whether SteamOS is in scope isn’t yet clear: its Arch-based system components are open source, but Valve distributes the image alongside the proprietary Steam client. GrapheneOS, which in March said it would refuse to comply with age-verification mandates, is distributed under open-source MIT and Apache licenses and now falls outside the law’s scope entirely, though Brazil’s Digital ECA still applies to it.

Assemblymember Buffy Wicks, who wrote both the Digital Age Assurance Act and the AB 1856 amendment, introduced the exemption back in February following criticism from Linux developers and the Electronic Frontier Foundation.

The development of Linux, a free ‘hobby’ operating system, was announced by Linus Torvalds 35 years ago today. On August 25, 1991, the unknown computer science student noted that the budding OS had been “brewing since April, and is starting to get ready.” The first public release of this ‘Minix-like’ OS came the following month, and in a last-minute change by the co-worker who uploaded it, was distributed with the name Linux instead of Freax. In 2026, Linux powers everything from smartphones to supercomputers and oodles of products, like the Steam Deck, in between.

The above commemorative post celebrates Torvalds’ stewardship over the Linux project. However, it is also quick to make clear that “hundreds of maintainers and thousands of contributors” have been instrumental to making this free open source OS a competitive, capable alternative to corporate/paid software, which can “move computing forward for humanity.”

Since 1991, Linux has come a long way on its journey from its humble ‘hobby’ OS beginnings. What started as a kernel with roughly 10,000 lines of code has exploded into 40 million or more lines today. Torvalds was humble about the first release yet proud of features like its multi-threaded filesystem, and the first release being clear of any borrowed Minix code. But the countless contributors over the last 35 years have helped forge an enviable OS, which boasts capabilities and features that must make it a worrying foe for commercial rivals.

There are areas, outside our PC and gaming core, where Linux is actually the biggest fish by far. Industry stats suggest that nearly 80% of web servers, and virtually all of the world’s Top500 supercomputers run a flavor of Linux. It dominates mobile too, with nearly 4 billion Android devices running Linux-derived kernels. Then there are all those embedded systems, encompassing things such as routers to automotive MCUs – so many run Linux.

I feel that Linux has made significant progress towards the fabled ‘year of Linux’ over the last couple of years. Microsoft’s Windows has been its own worst enemy in some respects, pushing people away due to a multitude of concerns. Meanwhile, consumers can see that content creation, productivity, and gaming on Linux PCs are continuously improving.

There was a recent collective sigh of relief in the Linux world, too. Earlier today, we reported on news that the decades-long Linux ownership dispute was effectively killed after Xinuos’ appeal was rejected by the U.S. Court of Appeals. That ruling means much lingering uncertainty over Linux devices facing future licensing claims, maker settlements, audits, and/or forced software rewrites has been banished.

A decades-long dispute over the ownership of Linux looks like it is over. Earlier this month, the United States Court of Appeals for the Second Circuit rejected Xinuos’ continued claims that IBM and Red Hat improperly contributed jointly‑developed Project Monterey UNIX code to Linux, reports The Register. Despite this deathly blow to its chances of extracting potential damages from IBM and Red Hat, and oodles of Linux royalties and licensing fees, Xinuos intends to seek a full‑bench rehearing. This appeal is a very long shot for Xinuos, with only 0.03% of such hearings granted, according to IBM’s legal representatives in the dispute.

This is a complicated case that spans decades. So, to make sense of what has happened over the years, we’ve constructed a timeline of key events, spanning from way back in 1998 to the present day.

• 1998 Project Monterey. IBM partnered with a firm called Santa Cruz Operation (SCO), Intel, and Sequent to build a unified UNIX running on multiple processor architectures. SCO’s contribution was largely related to Intel x86 code.
• 1998-2001. Linux enjoyed rapid growth, so the importance of Project Monterey waned. IBM saw the shifting sands and moved its focus to Linux.
• Early 2000s. SCO first complained that IBM contributed jointly‑developed UNIX code to Linux without having proper rights to do so. Litigation began.
• 2003. SCO’s first major lawsuit was filed against IBM. It asked for billions of dollars due to the aforementioned complaint of IBM’s unauthorized use of UNIX code in Linux.
• 2011. Xinuos bought SCO’s UNIX business and IP.
• 2021. The SCO heir settled with IBM for $14.25 million. That’s a far smaller sum than it asked for in 2003, which kind of reflects SCO’s failure to produce convincing legal evidence.
• 2021. Xinuos sued IBM and Red Hat, claiming that IBM knowingly breached its non‑exclusive license by contributing Monterey code to Linux.
• 2022-2025. Xinuos argued that IBM’s actions amounted to licensing violations, but the U.S. District Court (SDNY) rejected this claim.
• August 10, 2026. Xinuos’ appeals are rejected. The U.S. Court of Appeals for the Second Circuit ruled that the case was too old to relitigate, and Xinuos framed it as licensing but was really arguing ownership, which is time‑barred. Thus the District Court dismissal stood.
• Now, August 2026. Xinuos has announced that it will petition for a full‑bench rehearing of its case. However, this is a long shot with a 0.03% chance of a rehearing being granted. According to IBM’s defense law firm.

While Xinuos looks like it has run out of road on its Linux code ownership claims, that’s probably good for the computing community. IBM, Red Hat, and the open-source world can probably now rest a little easier, with the shadow cast in 2003 now nearly entirely removed. Lingering uncertainty over Linux’s legitimacy is evaporating with the Second Circuit’s affirmation that the case is time-barred, and rather hollow, legally.

Other companies contributing code to open source projects can also rest a little easier as this distracting, resource-draining litigation grinds to a halt. Success for Xinuous may have also meant billions of Linux devices facing licensing uncertainty, maker settlements, audits, and/or forced software rewrites.

Linux kernel 7.3 is set to bring an oddly nostalgic update for 3dfx's Voodoo 3, one of the most recognizable graphics cards of the late 1990s. Don't get too excited; the venerable PCI-and-AGP accelerator isn't suddenly getting a modern Linux graphics stack, but the kernel's existing tdfxfb framebuffer driver is being updated so that it can initialize a Voodoo 3 itself rather than relying on the system firmware to have already run the card's video BIOS. It's a small change with a surprisingly specific purpose, and one that illustrates why ancient hardware occasionally gets attention in contemporary Linux.

The problem is that the tdfxfb driver historically assumed that the Voodoo card had already been initialized by the PC's firmware. That's because, at the time it was written, that was a reasonable assumption on a conventional x86 PC. The system firmware would execute the card's video BIOS during boot, configure the hardware, and then hand Linux something that is already capable of displaying an image. That assumption breaks down on newer and unusual platforms where the firmware cannot or does not execute the VGABIOS. The creator's patch description specifically calls out non-x86 computers, systems where another graphics card is primary, and newer BIOSes that can't run the old video BIOS.

The developer behind the patches, Daniel Palmer, was using a Voodoo 3 in an Amiga 4000 equipped with a PCI bridge when the problem cropped up. Linux could detect the card, but the Voodoo was still completely uninitialized, leaving him staring at "no signal detected." The new code uses configuration information from the card's own video BIOS to perform the initialization from Linux instead, allowing the driver to bring the VGA core up and establish a working display without depending on the system firmware. For now, the new manual initialization code is specifically aimed at the Voodoo 3; he had initially noted support for the VSA-100-based Voodoo 4 and 5 cards, but their BIOS layouts are different, so that support was removed from the current patch series. The code has been tested on both a modern x86-64 system and an Amiga 4000 with a Mediator PCI bridge.

On a conventional modern-ish x86-64 PC with a Voodoo 3 installed, the practical result is fairly modest. Load tdfxfb and you can get a working Linux framebuffer device, typically exposed as /dev/fb0, with the Voodoo driving a display that can host the Linux virtual console. In other words, this is enough to turn the Voodoo from "a PCI device that Linux can identify" into an actual display adapter capable of putting pixels on the screen even when firmware didn't initialize it first. Applications that know how to use the Linux framebuffer interface can also draw to it, just as they could with other old framebuffer devices.

The thing is, that's also where the limits of this work become apparent. Linux fbdev is a legacy graphics interface and has long been superseded by Linux's DRM/KMS graphics infrastructure, so this ain't a resurrection of the Voodoo 3 as a contemporary Linux GPU. Loading tdfxfb does not give you a Mesa stack, modern OpenGL, Wayland acceleration, or the sort of 3D functionality you would expect. It is essentially a very old-fashioned "squirt pixels at the display" arrangement, but that's useful enough for a Linux console, embedded-style framebuffer applications, and, apparently, people putting exotic PCI graphics cards into even more exotic old computers, but it's not exactly a compelling reason to install a Voodoo 3 in a modern desktop.

The more interesting part is that Palmer is working on a separate 3D path for the Voodoo 3, and that effort is already much further along than the framebuffer work alone might suggest. The experimental interface exposes the Voodoo's register space to userspace through a new /dev/tdfx3d misc device, whose mmap() interface allows software to program the card's 3D hardware directly. On top of that sits smoltdfx, a tiny userspace library for driving the Voodoo 3, and smolminigl, a small OpenGL 1.x implementation built on top of it. Palmer says he has tested the project on real Voodoo 3 hardware and that it can render directly through the card's registers without X, Mesa, or Glide.

Palmer is developing that work alongside a QEMU emulation of the Voodoo 3. The developer says Claude helped build the emulator in the first place to debug the issue of getting the card working on his Amiga. Now, test programs can be run against both the emulated card and the real hardware, with differences fed back into the emulator until the behavior matches. The smoltdfx project now uses the same rendering tests against QEMU and physical Voodoo 3 hardware, comparing frame digests to catch differences. According to Palmer, the resulting MiniGL implementation can already run Quake on the real card, although performance isn't great, and some issues with the Voodoo 3's multitexturing capabilities remain to be worked out.

Obviously, that's a lot more interesting than simply putting a Linux console on a Voodoo 3. The sum total is a highly experimental 3dfx graphics stack built from the bottom up: Linux provides the framebuffer and low-level device access, userspace programs the Voodoo directly, and a lightweight OpenGL implementation sits above that to provide enough functionality for classic 3D software to command the card.

Indeed, things could get particularly fun for retro-computing and virtualization. A PCI Voodoo 3 is the sort of device that, at least conceptually, could be assigned to a virtual machine using PCI passthrough, letting a guest operating system talk directly to the real accelerator with its period-accurate 3dfx driver. In the fantasy version of that setup, you could have a modern Linux host hand an actual Voodoo 3 to a Windows 98 or DOS-era guest and then let the guest use the very same hardware that the old software expected. The engineering details are much nastier than the concept suggests (particularly around resetting and exposing such old hardware cleanly), but the new ability to initialize an otherwise-dormant Voodoo from Linux is at least a useful piece of that puzzle.

For now, though, the headline is more significant than the immediate feature set. Linux 7.3 isn't suddenly turning a 25-year-old Voodoo 3 into a usable GPU; it's making an existing framebuffer driver capable of bringing the card to life on systems where firmware cannot do the job, which is a very small but very real hole in hardware support. More remarkably, the same effort has already spilled into experimental 3D acceleration on real hardware, with a userspace Voodoo 3 library and an OpenGL implementation capable of running Quake. Voodoo 3 may be over 25 years old by now, but somebody is still teaching Linux new tricks with it in 2026.