Microsoft has publicly confirmed that its Azure Linux distribution is affected by a Linux kernel vulnerability tracked as CVE-2024-46754, but the company’s deliberately narrow advisory leaves administrators of other Microsoft-shipped Linux kernels—including WSL2, linux-azure, and CBL-Mariner based images—unsure whether their systems need patching. The advisory states that Azure Linux “includes the open-source library and is therefore potentially affected,” without making any claims about other products. Security teams must immediately patch Azure Linux instances and independently verify every other Microsoft-shipped Linux artifact in their environment.
The vulnerability at a glance
CVE-2024-46754 is a flaw in the Linux kernel’s BPF (Berkeley Packet Filter) subsystem, specifically in the seg6local (SRv6 local processing) program type. The upstream fix, summarized as “bpf: Remove tst_run from lwt_seg6local_prog_ops,” removes a test/dump path that mistakenly allowed certain BPF operations to be invoked via bpf_test_run without the seg6local runtime context being properly initialized. An attacker with the ability to load BPF programs could trigger incorrect behavior or kernel instability.
The vulnerability was resolved in stable kernel updates tracked by major distributions like Debian and Ubuntu, and the National Vulnerability Database (NVD) entry documents the fix. However, the impact on Microsoft’s products hinges on whether a given kernel build includes both the vulnerable code path and the affected BPF functionality.
Microsoft’s advisory: crystal clear for Azure Linux, opaque for everything else
On its Security Response Center (MSRC) page, Microsoft issued a product-scoped attestation for CVE-2024-46754, stating that Azure Linux includes the open-source library and is potentially affected. This is an authoritative, machine-readable signal: if you run Azure Linux images, you are in scope and must remediate.
The problem is that the advisory stops there. It does not mention WSL2 kernels, the linux-azure kernels used in many Azure VM SKUs, CBL-Mariner derived container hosts, or third-party Marketplace images. Microsoft’s own policy is to update CVE mappings and publish CSAF/VEX attestations only when an internal inventory confirms a product ships the vulnerable component. As of this advisory, only Azure Linux has been attested.
This leaves administrators in a classic “absence of evidence is not evidence of absence” situation. Just because Microsoft hasn’t named WSL2 doesn’t mean WSL2 is safe—it means nobody has publicly confirmed it one way or the other. Until Microsoft expands its attestation list or you perform your own checks, treat every other Microsoft-distributed kernel as potentially vulnerable.
What it means for you—by audience
Azure Linux administrators
You have the clearest path: your systems are explicitly in scope. Apply the latest kernel and image updates from Microsoft immediately and reboot. Follow Microsoft’s standard guidance for Azure Linux patching. No ambiguity here.
Windows users running WSL2
If you have WSL2 enabled on a Windows 10 or 11 machine, you are running a Microsoft-maintained Linux kernel that may contain the vulnerable code. The WSL2 kernel is built from a separate source tree and ships with its own configuration. While Microsoft hasn’t included it in this advisory, the kernel’s version and config could still expose you. Check your WSL kernel version with wsl --status (from the Windows host) or uname -r inside a WSL distribution. If it predates the upstream fix and has BPF/SRv6 enabled, you should either replace the WSL kernel with a patched build or apply mitigations.
IT teams managing mixed Azure estates
You likely use more than just Azure Linux images. Take inventory of every Linux artifact sourced from Microsoft:
- Azure VM instances using the linux-azure kernel (not to be confused with the Azure Linux distro)
- AKS node images
- CBL-Mariner based container hosts
- Third-party appliances from Azure Marketplace that may ship older kernels
Each of these must be checked independently, using the verification steps below.
Security engineers and compliance leads
This advisory is a test case for Microsoft’s evolving vulnerability disclosure process for Linux components. The company has committed to releasing CSAF/VEX attestations starting in October 2025, but until then, product-level advisories may be incomplete. Automate the ingestion of MSRC data and prepare for manual verification workflows when coverage is uncertain.
How we got here: the BPF kernel patch and Microsoft’s Linux obligations
The Linux kernel’s BPF subsystem has grown explosively, with program types stretching from networking to tracing to security enforcement. The seg6local program type, used for segment routing over IPv6, was introduced to allow flexible local processing of SRv6 packets. Like many BPF program types, it exposed a test-run interface that allowed developers to exercise programs in a controlled way. The vulnerability arose because that test-run hook could be called without the proper seg6local runtime context, leading to potential misuse.
Upstream maintainers removed the offending tst_run callback in a targeted patch. Distributions then picked up the fix through stable kernel trees. Microsoft’s own Linux distributions—Azure Linux (formerly CBL-Mariner) and WSL2—track these upstream changes but follow different release cadences and build configurations.
Microsoft’s approach to Linux security advisories has been industry-standard but cautious. Rather than blanket statements about all products, the company performs per-product inventory assessments and publishes attestations accordingly. This phased model reduces false positives but creates coverage gaps that customers must fill through their own verification.
What to do now: a practical action plan
1. Patch Azure Linux first (same-day priority)
This is the only confirmed target. Apply updates via your normal fleet management tools, redeploy patched VM images if needed, and reboot. No further investigation is required for Azure Linux itself.
2. Inventory every Microsoft-sourced Linux artifact in your environment
Gather a list of all systems that run a kernel or Linux image originally provided by Microsoft. Include:
- All Azure VM SKUs that might use the linux -azure kernel (check with uname -r; look for strings like “azure”)
- WSL2 instances on managed endpoints (use wsl --list --verbose from Windows)
- AKS node images (inspect node kernel versions through the AKS API or kubectl)
- CBL -Mariner containers (check base image digests and release notes)
- All Marketplace appliances that run Linux (identify the publisher and compare against published advisories)
3. Run quick verification commands on each suspect system
For any Linux host you need to check, execute these commands as root (or with sufficient privileges):
| Check | Command | What it tells you |
|---|---|---|
| Running kernel version | uname -r |
Map to vendor fix timelines; needed for further checks |
| BPF support compiled in | zgrep CONFIG_BPF /proc/config.gz (or /boot/config-$(uname -r)) |
If BPF not enabled, risk is negligible |
| Seg6 local module loaded | lsmod \| grep seg6_local |
Indicates the specific subsystem is active |
| Vendor changelog reference | rpm -q --changelog kernel \| grep -i 46754 (RHEL-based) or apt changelog linux-image-$(uname -r) \| grep -i 46754 (Debian/Ubuntu-based) |
Confirms if the fix was included |
If the kernel version is older than the fix date, BPF is enabled, and the changelog doesn’t list the CVE or upstream commit, treat the system as likely vulnerable.
4. Inspect WSL2 kernels on Windows hosts
From an administrator PowerShell, run:
wsl --status
Note the kernel version. Compare it against Microsoft’s WSL kernel release notes on GitHub. If the kernel predates the upstream fix (which landed in late September 2024) and the WSL config enables BPF (it does by default), consider taking one of these actions:
- Install the latest WSL kernel update from Microsoft’s WSL distribution channels.
- If you maintain custom WSL kernels, rebuild from source with the upstream patch applied.
- Mitigate risk by disallowing unfiltered BPF program loading through a custom kernel config or by using a non-BPF- dependent application profile.
5. Apply compensating controls while you patch
Not all systems can be updated immediately. Implement temporary mitigations:
- Restrict BPF loading by setting the kernel.unprivileged_bpf_disabled sysctl to 1 on hosts where unprivileged users shouldn’t load BPF programs.
- Revoke CAP_BPF and CAP_SYS_ADMIN from untrusted containers or processes.
- Isolate multi-tenant workloads on separate hosts until kernels are updated.
6. Prepare for ongoing automated attestation consumption
Microsoft’s CSAF/VEX feeds, expected to launch in October 2025, will provide machine-readable product mappings that vulnerability scanners can ingest. Integrate these feeds into your vulnerability management pipeline now so that as soon as a new product is attested for any CVE, an alert triggers. This will help catch future omissions without manual hunting.
Outlook: more attestations coming, but verify now
Microsoft has publicly committed to expanding its CVE-to-product mappings and publishing CSAF/VEX attestations as inventory assessments complete. For CVE-2024-46754, that means other products may eventually be named. Until then, the Azure Linux confirmation is your only guaranteed signal. Perform your own verification on every other system, document findings, and monitor Microsoft’s Security Update Guide for changes. When in doubt, patch—the manual verification steps above take minutes per host and can prevent a kernel-induced outage.