# kernels Hugging Face Kernels is a project and Python package for building, distributing, and loading compatible compute kernels from the Hub. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## More than 9,000 patches total in the seven stable kernels for Monday DevFeed: [More than 9,000 patches total in the seven stable kernels for Monday]() Original publisher: [Read original article]() Author: jzb Published: 2026-09-14T13:00:07Z Content type: news Language: en Sources: [LWN.net]() Topics: [kernels]() Tags: [kernels](), [upgrade]() ### AI overview Seven stable Linux kernels have received updates totaling more than 9,000 patches, including over 1,800 patches in version 7.2.6. Users are advised to upgrade. ### Source excerpt Greg Kroah-Hartman has announced the 7.2.6, 6.18.52, 6.12.110, 6.6.157, 6.1.188, 5.15.221, 5.10.270 stable kernels. According to Kroah-Hartman, this batch may set a record for the number of patches with more than 9,000 in total between them. There are more than 1,800 patches in 7.2.6 alone. Users of these kernels are, of course, advised to upgrade. ## BFS File-System Being Removed For Linux 7.4 DevFeed: [BFS File-System Being Removed For Linux 7.4]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-13T11:03:26Z Content type: news Language: en Sources: [Phoronix]() Topics: [Filesystems](), [Linux](), [kernels](), [Unix](), [boot]() Tags: [boot](), [bootloader](), [desktop-linux](), [filesystem](), [filesystems](), [kernels](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [os](), [phoronix](), [phoronix-test-suite](), [systems](), [technical](), [ubuntu-benchmarks](), [ubuntu-hardware]() ### AI overview BFS, the obsolete UnixWare boot-partition filesystem, is slated for removal from the Linux kernel in version 7.4. The article cites its extremely limited functionality, lack of likely users, and broader efforts to reduce maintenance burdens from rarely used filesystems. ### Source excerpt The latest upstream file-system to be removed from the mainline Linux kernel is... BFS... ## Two stable kernel updates for Friday DevFeed: [Two stable kernel updates for Friday]() Original publisher: [Read original article]() Author: jzb Published: 2026-09-11T13:27:35Z Content type: news Language: en Sources: [LWN.net]() Topics: [kernels]() Tags: [kernel](), [kernels](), [release](), [updates]() ### AI overview Greg Kroah-Hartman announced stable kernel updates 7.2.5 and 6.18.51, each containing more than 550 patches with fixes throughout the tree. Users are advised to upgrade. ### Source excerpt Greg Kroah-Hartman has announced the release of the 7.2.5 and 6.18.51 stable kernels. There are more than 550 patches in each with fixes throughout the tree; users are advised to upgrade. ## 🤗 Kernels: Major Updates DevFeed: [🤗 Kernels: Major Updates]() Original publisher: [Read original article]() Author: Sayak Paul; Daniël de Kok; David Holtz Published: 2026-07-06T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [kernels](), [Security](), [Open Source](), [Nix](), [Git](), [systems]() Tags: [git](), [hub](), [kernel-builder](), [kernels](), [open-source](), [optimization](), [sandbox](), [security](), [updates]() ### AI overview Hugging Face's Kernels project introduces a first-class "kernel" repository type on the Hub, allowing users to inspect supported accelerators, operating systems, and backend versions. The update also adds trusted publishers, code signing, reproducible Nix-based builds, and embedded Git source identifiers to improve security and provenance. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## From Exploit Code to Production Detection: Building a CVE-2026-31431 (Copy Fail) detection with Agents DevFeed: [From Exploit Code to Production Detection: Building a CVE-2026-31431 (Copy Fail) detection with Agents]() Original publisher: [Read original article]() Author: Ryan Simon Published: 2026-05-28T00:00:00Z Content type: article Language: en Sources: [Datadog Security Labs]() Topics: [Vulnerabilities](), [Linux](), [Detection engineering](), [kernels](), [Security](), [AI-assisted coding](), [Cryptography]() Tags: [agents](), [analysis](), [audit-trail](), [code](), [coding](), [engineering](), [kernel](), [kernels](), [linux](), [operations](), [security](), [vulnerabilities](), [vulnerability]() ### AI overview CVE-2026-31431, known as Copy Fail, allows an unprivileged local user to corrupt Linux page caches through AF_ALG sockets and escalate privileges to execute code as root. The article explains the exploit's kernel mechanisms and describes how Datadog Security Research used coding agents to develop and ship a detection in a single session. ### Source excerpt CVE-2026-31431 (Copy Fail) lets any unprivileged user corrupt the Linux page cache via AF_ALG sockets to escalate privileges. This post covers the exploit mechanics and how Datadog Security Research used coding agents to ship a detection content pack in a single session. ## Kubernetes v1.36: Tiered Memory Protection with Memory QoS DevFeed: [Kubernetes v1.36: Tiered Memory Protection with Memory QoS]() Original publisher: [Read original article]() Author: Qi Wang; Sohan Kunkerkar Published: 2026-04-29T18:35:00Z Content type: news Language: en Sources: [Kubernetes Blog]() Topics: [Kubernetes](), [configuration](), [observability](), [kernels]() Tags: [feature](), [kernels](), [kubernetes](), [memory](), [metrics](), [observability](), [v1]() ### AI overview Kubernetes v1.36 updates the alpha Memory QoS feature with opt-in memory reservation, tiered protection based on Pod QoS class, observability metrics, and a warning for kernels older than 5.9. Guaranteed Pods receive hard protection, Burstable Pods receive reclaimable soft protection, and BestEffort Pods remain fully reclaimable. ### Source excerpt On behalf of SIG Node, we are pleased to announce updates to the Memory QoS feature (alpha) in Kubernetes v1.36. Memory QoS uses the cgroup v2 memory controller to give the kernel better guidance on how to treat container memory. It was first introduced in v1.22 and updated in v1.27. In Kubernetes v1.36, we're introducing: opt-in memory reservation, tiered protection by QoS class, observability metrics, and kernel-version warning for memory.high. What's new in v1.36Opt-in memory reservation with memoryReservationPolicy v1.36 separates throttling from reservation. Enabling the feature gate turns on memory.high throttling (the kubelet sets memory.high based on memoryThrottlingFactor, default 0.9), but memory reservation is now controlled by a separate kubelet configuration field: None (default): no memory.min or memory.low is written. Throttling via memory.high still works. TieredReservation: the kubelet writes tiered memory protection based on the Pod's QoS class: Guaranteed Pods get hard protection via memory.min. For example, a Guaranteed Pod requesting 512 MiB of memory results in: $ cat /sys/fs/cgroup/kubepods.slice/kubepods-pod6a4f2e3b_1c9d_4a5e_8f7b_2d3e4f5a6b7c.slice/memory.min 536870912 The kernel will not reclaim this memory under any circumstances. If it cannot honor the guarantee, it invokes the OOM killer on other processes to free pages. Burstable Pods get soft protection via memory.low. For the same 512 MiB request on a Burstable Pod: $ cat /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod8b3c7d2e_4f5a_6b7c_9d1e_3f4a5b6c7d8e.slice/memory.low 536870912 The kernel avoids reclaiming this memory under normal pressure, but may reclaim it if the alternative is a system-wide OOM. BestEffort Pods get neither memory.min nor memory.low. Their memory remains fully reclaimable. Comparison with v1.27 behavior In earlier versions, enabling the MemoryQoS feature gate immediately set memory.min for every container with a memory request. memo ## GNU/Hurd developments and fixes in Q1 2026 DevFeed: [GNU/Hurd developments and fixes in Q1 2026]() Original publisher: [Read original article]() Published: 2026-03-02T06:07:00Z Content type: news Language: en Sources: [GNU Hurd]() Topics: [GNU/Hurd](), [Linux](), [kernels](), [Debian](), [bug](), [C](), [Deadlock](), [Documentation](), [Claude](), [qemu]() Tags: [2026](), [bug](), [c](), [claude](), [deadlock](), [debian](), [documentation](), [gnu-hurd](), [hardware](), [linux](), [qemu]() ### AI overview A Q1 2026 GNU/Hurd project update reports debugging and fixes across SMP, threading, filesystem, IPC, networking, and related components, along with wiki documentation and hardware-installation guidance. ### Source excerpt Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q1 of 2026! Details. Brent W. Baccala debugged some x86_64 SMP issues with a Claude AI bot. The bot did not contribute any code. It just found some incorrect code that Damien then fixed. It did get some things wrong, but it was incredibly helpful pointing out several problems. You can read its report here. Joshua Branson tweaked the hurd wiki. The most helpful addition is this page, which documents how to flash a working qemu hurd image directly to an HDD or SSD. This is a really easy way to install the Hurd on real hardware! Buy a supported machine from this page and give it a shot! Consider this another reminder that the Hurd project could use more documentation writers. It's an easy way to contribute. As a fun fact, Joshua wrote this qoth on the Hurd running on a T420 with 12 GB of RAM! Running Debian GNU/Hurd on bare metal these days is largely fairly stable. Emacs, i3, netsurf, and luakit all work just fine and most of the Debian package archive compiles without issue on the Hurd. Etienne Brateau fixed a compilation error. He also provided a simple test program that exposed a rather serious threading bug, which Samuel promptly fixed. This is a good reminder that writing simple C test programs that successfully run on Linux, but fail on the Hurd can have a large impact. Gianluca Cannata worked on our httpfs translator. Diego Nieto Cid added a daemon-wait option for console-client. This can help users with slow machines avoid a broken Hurd console. He also fixed a rumpdisk compilation issue. Mike Kelley fixed a deadlock in SMP enabled GNU Mach kernels. He also fixed a page fault in amd64 SMP kernels. He fixed another deadlock in the alarm () function. He fixed a panic when running large builds without the mach-defpager. He also fixed some of our signal related code. He worked with Samuel to investigate an odd bug. Their detailed investigation uncovered and lead to a fix in ## Redesigning my microkernel from the ground up DevFeed: [Redesigning my microkernel from the ground up]() Original publisher: [Read original article]() Author: January Published: 2026-01-12T00:00:00Z Content type: opinion Language: en Sources: [Drew DeVault]() Topics: [systems](), [Kernel](), [kernels](), [Development](), [Code](), [Unix]() Tags: [code](), [cpu](), [development](), [kernel](), [kernels](), [operating-systems](), [os](), [scheduler](), [systems](), [unix]() ### AI overview The author explains why the Helios microkernel project was abandoned after design and implementation problems, and describes starting Hermes from scratch while reusing selected code from Helios and Bunnix. Hermes is not yet feature-complete, but the author says it has a more robust design and supports symmetric multiprocessing. ### Source excerpt As you may recall, circa 2022-2023 I was working on a microkernel written in Hare named Helios. Helios was largely inspired by and modelled after the design of seL4 and was my first major foray into modern OS development that was serious enough to get to a somewhat useful state of functionality, with drives for some real hardware, filesystems, and an environment for running user programs of a reasonable level of sophistication. Helios development went strong for a while but eventually it slowed and eventually halted in a state of design hell. Since Helios was my first major OS project at this scale and with this much ambition, the design and implementation ended up with a lot of poor assumptions that made it a pretty weak foundation for building a complete OS upon. In late 2023 I more or less gave up on it and moved my OS development work out of the realm of writing code and back into the realm of thinking really hard about how to design operating systems. What followed was a couple of years of design thinking, developing small scale design experiments, and doing deeper research into prior art - reading papers and studying existing kernels. It was also during this period that I wrote Bunnix, a working Unix clone, motivated in part by a desire to gain some first-hand experience working in the design and implementation of Unix-style operating systems - a fertile environment for learning a lot of the nuts and bolts of OS implementations by working against a complete and proven design. In August I was finally prepared to have another go. I decided to start over from scratch, importing and adapting and rewriting code from Helios and Bunnix on an as-needed basis to speed things up, and writing from scratch anything where the lessons learned in hindsight outweighed the benefits of adapting existing code.1 The result is Hermes. Hermes has not yet reached feature parity with Helios, lacking some IPC features and an aarch64 port, but already it's significantly more robust and ## Easily Build and Share ROCm Kernels with Hugging Face DevFeed: [Easily Build and Share ROCm Kernels with Hugging Face]() Original publisher: [Read original article]() Author: Abdennacer Badaoui; Daniel Huang; colorswind; Zesen Liu Published: 2025-11-17T00:00:00Z Content type: tutorial Language: en Sources: [Hugging Face - Blog]() Topics: [kernels](), [rocm](), [hugging face](), [PyTorch](), [Deep learning](), [Open Source](), [benchmarking](), [CUDA]() Tags: [amd](), [architectures](), [best-practices](), [build](), [building](), [compiler](), [compute](), [core](), [cuda](), [deep-learning](), [deployment](), [developer](), [gpu](), [hardware](), [hugging-face](), [innovation](), [kernels](), [open-source](), [pytorch](), [rocm]() ### AI overview This tutorial explains how to build, test, package, deploy, and share ROCm-compatible GPU kernels with Hugging Face's kernels library and kernel-builder. It focuses on integrating kernels with PyTorch and optimizing them for AMD GPUs, using a high-performance FP8 GEMM kernel for the AMD Instinct MI300X as an example. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## Creating custom kernels for the AMD MI300 DevFeed: [Creating custom kernels for the AMD MI300]() Original publisher: [Read original article]() Author: Rémi Ouazan Reboul; seungrok jung Published: 2025-07-09T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [kernels](), [GPU](), [vllm](), [hugging face](), [model-deployment](), [Optimization](), [llama](), [Open Source]() Tags: [amd](), [cuda](), [gpu](), [hugging-face](), [inference](), [kernels](), [latency](), [llama](), [open-source](), [optimization](), [vllm]() ### AI overview Hugging Face and AMD describe open-source, device-specific kernel optimizations for serving Llama 3.1 405B in FP8 with vLLM on eight AMD MI300X GPUs. The article explains kernel-level optimization and reports latency improvements from fused residual, normalization, FP8 conversion, SwiGLU, and Skinny GEMM kernels. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## Mobian's Early 2025 Developments: Debian Packages, Device Support, and a New Login Screen DevFeed: [Mobian's Early 2025 Developments: Debian Packages, Device Support, and a New Login Screen]() Original publisher: [Read original article]() Author: Mobian team Published: 2025-02-19T00:00:00Z Content type: article Language: en Sources: [Mobian's Blog]() Topics: [Mobile](), [Debian](), [GTK](), [kernels](), [Wayland]() Tags: [adaptive](), [debian](), [kernels](), [mobile](), [patches](), [wayland]() ### AI overview The article reviews recent Mobian developments, including new device support, improved Debian and Mobian packages, plans to reduce the Mobian package repository to mostly Mobian-specific and hardware-support packages, and progress toward a new default mobile login screen. ### Source excerpt Over the past few months, and especially since the last holiday season, many exciting things have happened in Mobian: new devices are (about to be) officially supported, many new and improved packages have made their way into both Debian and Mobian, and we're getting ready for our next stable release! Towards a "device-specific only" repository Thanks to the involvement of upstream developers (by either accepting or writing patches to ensure their applications can be used on mobile devices) and the work of the relevant Debian teams, many GNOME and KDE apps were made adaptive and could be uploaded to the main Debian archive without any additional downstream patch. This allowed us to drop (almost) all of the applications we were distributing through the Mobian package repository: Evince has been replaced with Papers, Loupe is now used instead of EOG and our main camera app is now Snapshot, all available directly from Debian! GNOME Text Editor now works well enough on mobile devices, as do Software and Settings We plan on getting rid of the remaining few ones before the Trixie release: Millipixels (Librem 5 camera app) will be replaced by Megapixels v2 once it hits the Debian archive wake-mobile will likely be dropped as it's no longer maintained, and upstream offers .deb packages for download anyway Except for a patched version of GTK 3 which we will keep maintaining until Phosh is ported to GTK 4, this means all packages in the Mobian archive will be either Mobian-specific (mainly metapackages) or hardware support packages (kernels and device-specific tweaks). A better tomorrow greeter Another major milestone we're about to reach is the move to a new default login screen: back in 2022, we decided that user session management on mobile devices shouldn't get any special treatment, and we should rely on a "display manager" similar to GDM/LightDM/SDDM, for instance. This would bring many benefits, the most prominent ones being multi-user setups for those who need it (e.g ## Using Bosque in JupyterLab DevFeed: [Using Bosque in JupyterLab]() Original publisher: [Read original article]() Author: brakmic Published: 2025-01-17T16:17:39Z Content type: tutorial Language: en Sources: [Harris Brakmic - Coding]() Topics: [Bosque](), [jupyterlab](), [Programming language](), [Extension](), [kernels](), [Python](), [TypeScript](), [Programming]() Tags: [article](), [bosque](), [coding](), [extensions](), [jupyter](), [jupyterlab](), [kernel](), [kernels](), [python](), [syntax-highlighting](), [typescript]() ### AI overview The article discusses Bosque, a Microsoft Research programming language centered on regularized programming, immutable state, and intent-focused coding. It also describes the author's experience building JupyterLab extensions and kernels, including Python-based kernels and TypeScript syntax highlighting with Lezer parsers. ### Source excerpt Discover the innovative world of Bosque, a programming language developed by Microsoft Research that champions the regularized programming paradigm. In this post, I explore the key advantages of Bosque, such as immutable state and intent-focused coding, and share my journey integrating it into JupyterLab. Learn how I developed custom kernels in Python and crafted syntax highlighting extensions using TypeScript and Lezer parsers. Whether you're intrigued by Bosque's approach or looking to enhance your JupyterLab environment, this article provides valuable insights and practical guidance to help you get started. Dive in to see how Bosque can transform your programming experience and streamline your development workflow! ## Bringing Interactive Computing to Zed: Introducing REPL Support DevFeed: [Bringing Interactive Computing to Zed: Introducing REPL Support]() Original publisher: [Read original article]() Author: Kyle Kelley Published: 2024-07-24T00:00:00Z Content type: release Language: en Sources: [Zed Industries - Blog]() Topics: [Development](), [jupyter](), [kernels](), [Python](), [Deno](), [R](), [Markdown]() Tags: [analysis](), [code](), [development](), [jupyter](), [jupyter-notebooks](), [kernel](), [kernels](), [language](), [markdown](), [python](), [release](), [typescript]() ### AI overview Zed introduces a built-in REPL that lets users run code line by line, block by block, or from a selection, visualize data, and iterate within the editor. The feature integrates REPL-style interaction with Jupyter-like output and supports installed kernels for languages including Python, TypeScript through Deno, and R. ### Source excerpt Run code, visualize data, and iterate right in your editor with Zed's new REPL support. ## Mounting into mount namespaces DevFeed: [Mounting into mount namespaces]() Original publisher: [Read original article]() Author: Christian Brauner Published: 2023-02-27T23:00:00Z Content type: article Language: en Sources: [Personal blog of Christian Brauner]() Topics: [mount](), [kernels](), [file](), [coding]() Tags: [coding](), [filesystem](), [kernels](), [mount]() ### AI overview This article examines how to insert new mounts into a running container's mount namespace. It discusses the complexity of mount operations, a legacy userspace path-verification approach, and a newer approach intended to prevent symlink attacks by verifying paths and opening their final components before mounting. ### Source excerpt Introduction ## 2021-05-17 Status update DevFeed: [2021-05-17 Status update]() Original publisher: [Read original article]() Author: Mobian team Published: 2021-05-17T00:00:00Z Content type: release Language: en Sources: [Mobian's Blog]() Topics: [Linux](), [Mobile](), [Debian](), [Development](), [kernels](), [maintenance](), [Tooling]() Tags: [debian](), [development](), [linux](), [maintenance](), [mobile](), [phones](), [porting](), [tooling](), [update](), [updated]() ### AI overview This Mobian status update reports progress on distribution stability and tooling, the positive reception of the Mobian Community Edition PinePhone, donations to Debian and investment in infrastructure, and official support for the Pocophone F1 and OnePlus 6 and 6T. The newly supported phones remain unsuitable as daily drivers because modem, audio, and camera functionality is not yet working. ### Source excerpt The past few months have been quieter than usual regarding Mobian development, but that's not to say we didn't make progress! Actually, even though user-visible changes are few, we kept working on improving both the stability of our distribution and our tooling, so that new developments can be better tested, and reach users faster than they used to. Mobian CE reception and outcomes The Mobian Community Edition PinePhone has been a great success for us, with of course a few hiccups, but the feedback we received so far has been extremely positive. We'd like to take this opportunity to thank Pine64 once again for allowing us to be part of this amazing journey! As you probably know, Pine64 generously donated 10$ per device to the Mobian project, which we received early last month. Out of this amount, we chose to donate 5000EUR back to the Debian project (which provides the foundation for all of our work on Mobian), and invested about the same amount into our own infrastructure (workstation, build servers...). Finally, we purchased a few additional mobile devices we considered interesting targets and started porting Mobian to those. New supported devices Let's play with Android phones! Until recently, Mobian supported only Pine64's PinePhone, PineTab and Purism's Librem 5. This is partly related to our choice of only using mainline kernels, instead of vendor-provided Android kernels: those use a number of non-standard interfaces, and require additional software, such as Halium, in order to be used with a "standard" Linux userspace. In addition, vendor kernels are generally outdated and very rarely updated to newer kernel releases, which is obviously a concern for long-term maintenance. Fortunately, our friends at postmarketOS have committed to mainlining devices for quite some time now, and by encouraging such development have reached great results so far! Based on their initiative, and more specifically thanks to @calebccff's and @Joel's work on the SDM845 kernel, we have b ## ReactOS 0.4.6 released DevFeed: [ReactOS 0.4.6 released]() Original publisher: [Read original article]() Published: 2017-09-01T00:00:00Z Content type: release Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [version](), [Hardware](), [boot](), [kernels]() Tags: [compatibility](), [drivers](), [dual-boot](), [filesystem](), [free](), [hardware](), [kernels](), [loader](), [open-source](), [os](), [partitions](), [react](), [reactos](), [release](), [smb](), [software](), [tests](), [user-experience](), [version](), [win32](), [winapi]() ### AI overview The ReactOS Project released version 0.4.6, highlighting improvements in real hardware support, dual-boot and partition handling, custom kernel loading, drivers, application compatibility, user experience, and system stability. ### Source excerpt The ReactOS Project is pleased to release version 0.4.6 as a continuation of its three month cadence. 0.4.6 is a major step towards real hardware support. Several dual boot issues have been fixed and now partitions are managed in a safer way avoiding corruption of the partition list structures. ReactOS Loader can now load custom kernels and HALs. Printing Subsystem is still greenish in 0.4.6, however Colin Finck has implemented a huge number of new APIs and fixed some of the bugs reported and detected by the ReactOS automated tests. ## Lightweight Linux Kernel Development with KVM DevFeed: [Lightweight Linux Kernel Development with KVM]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2013-12-30T02:11:45Z Content type: tutorial Language: en Sources: [Nelson Elhage]() Topics: [Development](), [kernels](), [Kernel](), [Disk image](), [Debian](), [Ubuntu](), [networking]() Tags: [debian](), [development](), [features](), [image](), [kernels](), [kvm](), [linux](), [linux-kernel](), [networking](), [ubuntu](), [virtio]() ### AI overview A practical workflow for Linux kernel development using lightweight virtual machines with KVM. It covers minimal kernel configuration, building a Debian userspace disk image, booting the guest with virtio, and configuring networking, with notes for different architectures. ### Source excerpt I don't do a ton of Linux kernel development these days, but I've done a fair bit in the past, and picked up a number of useful techniques for doing kernel development in a relatively painless fashion. This blog post is a writeup of the tools and techniques I use when developing for the Linux kernel. Nothing I write here is "the one way" to do it, but this is a workflow I've found to work for me, that I hope others may find useful. ## Some notes on CVE-2010-3081 exploitability DevFeed: [Some notes on CVE-2010-3081 exploitability]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2010-11-30T12:58:01Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [Linux](), [Vulnerabilities](), [bug](), [Exploit](), [kernels]() Tags: [bug](), [cve](), [exploit](), [kernels](), [linux]() ### AI overview This article examines CVE-2010-3081, a Linux kernel vulnerability that enabled local privilege escalation on many 64-bit systems. It argues that commonly reported facts about the vulnerability were incorrect and that disabling 32-bit binaries did not fully prevent exploitation. ### Source excerpt Most of you reading this blog probably remember CVE-2010-3081. The bug got an awful lot of publicity when it was discovered an announced, due to allowing local privilege escalation against virtually all 64-bit Linux kernels in common use at the time. While investigating CVE-2010-3081, I discovered that several of the commonly-believed facts about the CVE were wrong, and it was even more broadly exploitable than was publically documented. I'd like to share those observations here.