Debian 12 Linux Kernel 6.12.113-1 Update Fixes Privilege Escalation, DoS, and Information Leak Flaws — Patch and Verification Guide

Debian's LTS security team has released an update for the Linux 6.12 kernel in Debian 12 (bookworm), fixing multiple vulnerabilities that allow unauthorized privilege escalation, denial of service, and information disclosure from kernel memory. The fixed version is 6.12.113-1~deb12u1, published under advisory DLA-4850-1.

This is not an advisory you can queue for next quarter's maintenance window. Kernel-level privilege escalation flaws are the connective tissue of modern intrusions: the initial foothold is often a low-value web shell or phished user account, and a local kernel exploit is what converts that foothold into full root control of the host — and from there, your hypervisor, your containers, and your backup infrastructure. Any multi-user Debian 12 system, internet-facing server, CI/CD runner, or container host running an unpatched 6.12-series kernel is carrying exploitable risk from any local actor, including compromised service accounts and container workloads with insufficient isolation.

The Debian advisory itself notes the update bundles a large set of upstream stable fixes. When a kernel point release carries that many changes, the practical message for defenders is simple: treat the kernel as a unit and patch it, rather than attempting to cherry-pick individual subsystem fixes.

Technical Analysis

Affected Products and Versions

• Distribution: Debian GNU/Linux 12 (bookworm)
• Package: linux-6.12 source package and all derived binary images (linux-image-6.12.x-amd64, linux-image-6.12.x-cloud-amd64, linux-image-6.12.x-arm64, and related -unsigned, -dbg, and header packages)
• Vulnerable: All 6.12-series kernel builds in bookworm prior to 6.12.113-1~deb12u1
• Fixed: 6.12.113-1~deb12u1

Note that Debian 12 systems still running the older 6.1-series kernel are tracked under a separate package and advisory stream — do not assume this update covers them. Inventory both tracks in your environment.

Vulnerability Classes Disclosed

The advisory does not enumerate individual CVE identifiers in its summary, but it describes three impact classes that map directly to the attack patterns we see in kernel exploitation:

1. Privilege escalation. Local elevation of privilege (LPE) bugs in the kernel are typically triggered by an unprivileged or low-privileged process exercising a vulnerable code path — common historical vectors include netfilter, io_uring, eBPF, namespace handling, and filesystem drivers. Exploitation requires local code execution (an existing shell, a compromised daemon, or a container breakout), after which the attacker gains root/CAP_SYS_ADMIN-equivalent control.
2. Denial of service. Kernel oopses, NULL dereferences, use-after-free triggers, and soft lockups can be induced locally or, in some subsystems (networking stack, packet parsing), remotely. For internet-facing hosts, remotely triggerable DoS is an availability incident waiting for a scanner to find it.
3. Information leaks. Uninitialized kernel memory returned to userspace can expose credentials, key material, pointer values (defeating KASLR), and fragments of other processes' memory. KASLR defeats are particularly dangerous because they turn unreliable exploits into reliable ones — an info leak plus an LPE primitive is a complete chain.

Exploitation Requirements and Status

• Attack vector: Primarily local. The attacker needs the ability to execute code on the target host — via a compromised user account, a vulnerable network service, an SSH session, or a containerized workload sharing the host kernel.
• Privileges required: Low. By definition, an LPE chain starts from an unprivileged position.
• Public exploitation status: The Debian summary does not confirm in-the-wild exploitation or name a CISA KEV entry. However, Debian stable kernel point releases routinely incorporate fixes for upstream bugs that already have public discussion or proof-of-concept code by the time the package lands. Assume motivated attackers can and will diff this release against the prior one to identify the patched code paths — the patch gap is the exploitation window.

Why This Matters Beyond Standalone Servers

The kernel is a shared trust boundary in places administrators forget about:

• Container hosts. Every container on a Docker, containerd, or Kubernetes node shares the host kernel. A local kernel exploit from inside a container is a container escape. Unpatched nodes turn any compromised pod into a node compromise.
• Virtualization hosts. KVM/QEMU hosts running bookworm expose the kernel to guest-driven syscall patterns.
• CI/CD runners. Build agents execute untrusted code by design (pull requests, third-party actions). An unpatched runner kernel is a supply-chain escalation path.
• Appliances and vendor images. Many network and security appliances are Debian-based under the hood. Verify whether your vendors ship the 6.12 series.

Detection & Response

Patching is the fix, but you should assume some systems were exposed before you patched them. Hunt for evidence of local privilege escalation and post-exploitation behavior on Debian hosts — especially anything internet-facing or multi-tenant. The detections below target the behaviors that kernel LPE exploitation produces (unexpected root processes, kernel module tampering, namespace/sandbox escape tooling), not a specific CVE, because the advisory aggregates multiple fixes.

Sigma Rules

---
title: Linux Kernel Exploit Post-Exploitation - Unexpected Root Shell or Setuid Execution
id: 2b6f1a90-4c3d-4e51-9a77-d8e2c1f5a901
status: experimental
description: Detects interactive shells and common post-exploitation tools executed with UID 0 from parents that should not produce root shells (web servers, databases, container runtimes), consistent with successful local privilege escalation via a kernel flaw on Debian 12 hosts.
references:
  - https://linuxsecurity.com/advisories/deblts/debian-dla-4850-1-linux-6-12
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection_shell:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/socat'
      - '/nc'
      - '/ncat'
  selection_parent:
    ParentImage|endswith:
      - '/nginx'
      - '/apache2'
      - '/httpd'
      - '/php-fpm'
      - '/java'
      - '/node'
      - '/postgres'
      - '/mysqld'
      - '/mongod'
      - '/containerd'
      - '/dockerd'
      - '/runc'
      - '/kubelet'
  condition: selection_shell and selection_parent
falsepositives:
  - Legitimate application debugging by administrators
  - Management agents executing health-check scripts
level: high
---
title: Linux Suspicious Kernel Module or eBPF Loading Activity
id: 8c4d2e71-5a6b-4f38-b1c2-e9f3a7d60482
status: experimental
description: Detects kernel module insertion, module parameter tampering, or eBPF program loading by interactive users, a common follow-on step after local privilege escalation and a technique used by kernel exploits and rootkits to establish persistence on Debian hosts.
references:
  - https://linuxsecurity.com/advisories/deblts/debian-dla-4850-1-linux-6-12
  - https://attack.mitre.org/techniques/T1547/006/
  - https://attack.mitre.org/techniques/T1014/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1547.006
  - attack.defense_evasion
  - attack.t1014
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/insmod'
      - '/modprobe'
      - '/rmmod'
    User|contains:
      - 'www-data'
      - 'wwwrun'
      - 'apache'
      - 'nginx'
      - 'nobody'
      - 'daemon'
  condition: selection
falsepositives:
  - Rare; service accounts should essentially never load kernel modules
level: critical
---
title: Linux Namespace Escape and Sandbox Tooling by Unprivileged Users
id: 5f1a9c83-7d2e-4b64-a3f1-c8e5b20947d3
status: experimental
description: Detects use of unshare, nsenter, or setpriv by non-root service accounts, indicating attempts to manipulate namespaces or escape confinement — a frequent primitive in Linux kernel privilege escalation chains and container breakouts.
references:
  - https://linuxsecurity.com/advisories/deblts/debian-dla-4850-1-linux-6-12
  - https://attack.mitre.org/techniques/T1068/
  - https://attack.mitre.org/techniques/T1611/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.t1611
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/unshare'
      - '/nsenter'
      - '/setpriv'
  selection_user:
    User|contains:
      - 'www-data'
      - 'apache'
      - 'nginx'
      - 'nobody'
      - 'daemon'
      - 'git'
      - 'jenkins'
  condition: selection and selection_user
falsepositives:
  - CI/CD pipelines using namespace isolation under dedicated service accounts (tune per account)
level: high

Microsoft Sentinel / Defender KQL

If your Debian fleet forwards syslog and auditd data to Sentinel (via the Syslog/CEF connector or the Azure Monitor Agent), hunt for kernel fault events and privilege transitions. Kernel oopses and repeated segfaults from the same process are a hallmark of exploit attempts — including failed attempts, which are exactly what you want to catch before the attacker tunes the exploit.

// Hunt: kernel faults, oopses, and privilege escalation signals on Debian 12 hosts (last 14 days)
let Lookback = 14d;
union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(Lookback)
    | where SyslogMessage has_any ("kernel: BUG", "Oops", "general protection fault", "segfault at", "KASAN", "use-after-free", "null-ptr-deref", "unable to handle kernel")
    | project TimeGenerated, Computer, HostIP, ProcessName, SyslogMessage
    | extend Signal = "KernelFault"),
    (Syslog
    | where TimeGenerated > ago(Lookback)
    | where Facility =~ "authpriv" or ProcessName =~ "sudo"
    | where SyslogMessage has_any ("authentication failure", "NOT in sudoers", "command not allowed")
    | summarize AuthFailures = count(), Samples = make_set(SyslogMessage, 5) by Computer, TimeGenerated = bin(TimeGenerated, 1h)
    | where AuthFailures > 10
    | extend Signal = "SudoBruteOrAbuse")
| order by TimeGenerated desc

// Hunt: service-account processes spawning shells or namespace tooling (Linux via Syslog/auditd ingestion)
let ServiceAccounts = dynamic(["www-data", "nginx", "apache", "nobody", "daemon", "postgres", "mysql"]);
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("unshare", "nsenter", "setpriv", "insmod", "modprobe", "/bin/bash", "/bin/sh")
| where SyslogMessage has_any (ServiceAccounts)
| summarize Events = count(), SampleCommands = make_set(SyslogMessage, 10) by Computer, ProcessName, bin(TimeGenerated, 15m)
| order by Events desc

Velociraptor VQL

Use this artifact to sweep your Debian fleet for hosts still running a vulnerable 6.12-series kernel and to flag out-of-tree or unexpected kernel modules — a persistence signal after kernel compromise.

-- Artifact: Debian 12 linux-6.12 patch verification and kernel module audit
-- Identifies hosts running kernels older than 6.12.113-1~deb12u1 and lists loaded modules

LET kernel = SELECT * FROM execve(argv=['uname', '-r'])

LET debian_ver = SELECT * FROM execve(argv=['dpkg-query', '-W', '-f=${Version}', 'linux-image-amd64'])

LET modules = SELECT * FROM parse_file(filename='/proc/modules',
                                       accessor='data')

SELECT
    { SELECT Stdout FROM kernel } AS RunningKernel,
    { SELECT Stdout FROM debian_ver } AS InstalledImageVersion,
    iff(condition={ SELECT Stdout FROM debian_ver } =~ '6\\.12\\.113-1',
        then='PATCHED',
        else='REVIEW_REQUIRED') AS PatchStatus,
    { SELECT count() FROM modules } AS LoadedModuleCount
FROM scope()

-- Hunt: processes running as root whose parent is a network-facing service
-- Post-exploitation indicator consistent with successful local privilege escalation

SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       get_process_ppid_name(pid=Ppid) AS ParentName
FROM pslist()
WHERE (Username =~ 'root')
  AND ParentName =~ '(?i)(nginx|apache|httpd|php-fpm|java|node|postgres|mysql|containerd|dockerd|runc|kubelet|sshd)'
  AND Name =~ '(?i)(bash|sh|dash|zsh|python|perl|socat|nc|ncat|curl|wget)'

Note: get_process_ppid_name is illustrative — in production, join pslist() against itself on Ppid. Adjust to your Velociraptor deployment's available functions.

Remediation and Verification Script

Run the following on Debian 12 hosts (or deploy via Ansible/Salt across the fleet). It checks the running kernel, applies the security update, verifies the installed version meets the fixed baseline, and flags hosts that need a reboot to activate the new kernel.

#!/usr/bin/env bash
# Debian 12 linux-6.12 remediation — DLA-4850-1 (fixed: 6.12.113-1~deb12u1)
set -euo pipefail

FIXED_VER="6.12.113-1"

echo "=== Running kernel ==="
uname -r

echo "=== Refreshing package index ==="
apt-get update -qq

echo "=== Installed linux-image packages (6.12 series) ==="
dpkg-query -W -f='${Package} ${Version}\n' 'linux-image-6.12*' 2>/dev/null || echo "No 6.12-series images found (host may run 6.1 series — check separate advisory)"

echo "=== Applying kernel security update ==="
DEBIAN_FRONTEND=noninteractive apt-get install -y --only-upgrade \
  $(dpkg-query -W -f='${Package}\n' 'linux-image-6.12*' 'linux-headers-6.12*' 2>/dev/null | tr '\n' ' ') || \
  echo "[!] No upgradeable 6.12 packages — verify apt sources include bookworm-security/updates"

echo "=== Post-update verification ==="
NEW_VER=$(dpkg-query -W -f='${Version}' linux-image-6.12*-amd64 2>/dev/null | sort -V | tail -n1 || true)
echo "Newest installed 6.12 image version: ${NEW_VER:-none}"

if dpkg --compare-versions "${NEW_VER:-0}" ge "${FIXED_VER}"; then
  echo "[OK] Installed kernel meets or exceeds fixed baseline ${FIXED_VER}"
else
  echo "[FAIL] Kernel still below ${FIXED_VER} — investigate apt sources/mirrors"
  exit 1
fi

echo "=== Reboot requirement check ==="
RUNNING=$(uname -r)
if [[ "${RUNNING}" == *"${FIXED_VER%%-*}"* ]] || [[ "${RUNNING}" == *"6.12.113"* ]]; then
  echo "[OK] Running kernel appears current"
else
  echo "[ACTION REQUIRED] Running kernel (${RUNNING}) predates the patched image. Schedule reboot to activate."
  # Optional: unattended reboot
  # shutdown -r +5 "Kernel security update DLA-4850-1 applied — rebooting"
fi

echo "=== Integrity spot-check ==="
dpkg -V linux-image-$(uname -r) 2>/dev/null | head -20 || true
echo "Done."

Operational notes:

• The patch is not live until the reboot. apt installs the new image alongside the old one; the vulnerable kernel keeps running until you restart. Track "installed vs. running" version drift in your CMDB or via the VQL artifact above — this gap is where post-patch compromises happen.
• Stagger reboots for clustered workloads (Kubernetes nodes, database replicas) to preserve availability, but do not defer them.
• Container hosts and CI runners first. They execute semi-trusted code and give attackers the local execution prerequisite for free.

Remediation

1. Patch immediately. Update all Debian 12 (bookworm) systems running the 6.12-series kernel to 6.12.113-1~deb12u1 via your configured bookworm security repositories. Verify with dpkg-query -W 'linux-image-6.12*' and confirm the running kernel with uname -r after reboot.
2. Reboot to activate. A kernel update without a reboot changes nothing at runtime. Prioritize internet-facing hosts, multi-tenant systems, Kubernetes/containerd nodes, CI/CD runners, and virtualization hosts.
3. Audit for pre-patch compromise. Because these flaws enable privilege escalation from any local foothold, review hosts that were exposed before patching: check for unexpected root processes, new SUID binaries (find / -perm -4000 -newer /var/lib/dpkg/status -type f), unauthorized kernel modules (lsmod against a known-good baseline), and new local user accounts or SSH keys.
4. Reduce local attack surface while patching rolls out:
   • Restrict interactive shell access and enforce least privilege on service accounts.
   • On hosts that don't need it, restrict unprivileged user namespaces (sysctl kernel.unprivileged_userns_clone=0 where supported) and eBPF for unprivileged users (sysctl kernel.unprivileged_bpf_disabled=1) — both are common kernel-exploit prerequisites. Test before broad rollout; some container tooling depends on user namespaces.
   • Ensure auditd is running and forwarding to your SIEM so post-exploitation signals are captured.
5. Verify downstream images. Rebuild container base images and VM templates/AMIs derived from bookworm so newly provisioned infrastructure doesn't reintroduce the vulnerable kernel.
6. Track the advisory. Monitor the Debian security tracker and the upstream source advisory (DLA-4850-1) for the enumerated CVE list and any subsequent follow-up updates; subscribe to debian-security-announce if you haven't already.
7. Close the loop in your vuln management program. Add a SLA for kernel security updates on shared/multi-tenant hosts (we recommend 72 hours for privesc-class kernel fixes on exposed systems), and measure "installed-but-not-running" reboot debt as a first-class metric.

Executive Takeaways

Kernel advisories that bundle privilege escalation, DoS, and information leaks in a single point release are high-priority by definition — the LPE component turns any minor foothold into full host compromise. Patch to 6.12.113-1~deb12u1, reboot, hunt for pre-patch escalation artifacts, and treat container hosts and CI runners as your front line.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub