Inserting seccomp notify filter in WSL kernel 5.15.83.1 fails with EBUSY

Version

Microsoft Windows [Version 10.0.22621.1245]

WSL Version

WSL 2
WSL 1

Kernel Version

5.15.83.1-microsoft-standard-WSL2

Distro Version

Ubuntu 22.04

Other Software

No response

Repro Steps

Starting with WSL kernel 5.15.83.1, there is an issue inserting seccomp filters that have the "notify" action (see SECCOMP_FILTER_FLAG_NEW_LISTENER in the Linux seccomp man page). Inserting such filters returns EBUSY from the kernel.

Possible cause is that PID 1 in the WSL distro appears to have a seccomp filter attached to it by default:

wsl -d Ubuntu-22.04

$ grep -i seccomp /proc/1/status
Seccomp:        2
Seccomp_filters:        1        <<< HERE

I believe the presence of this filter on PID 1 is causing the problem: the filter is inherited by all child processes in the distro, and therefore a child process that tries to insert a seccomp notify filter (SECCOMP_FILTER_FLAG_NEW_LISTENER) gets an EBUSY response from the kernel since only one such filter per process is allowed.

The problem does NOT occur in WSL kernel 5.15.79.1. In that kernel, PID 1 has no seccomp filter on it (as expected):

$ grep -i seccomp /proc/1/status
Seccomp:        0
Seccomp_filters:        0

Expected Behavior

A process running in a WSL Linux distro should be able to insert a seccomp notify filter (SECCOMP_FILTER_FLAG_NEW_LISTENER) without problem.

In addition, PID 1 in the WSL Linux distro should not have a seccomp filter attached to it by default.

Actual Behavior

Starting with WSL kernel 5.15.83.1, inserting seccomp filters that have the "notify" action (SECCOMP_FILTER_FLAG_NEW_LISTENER) returns EBUSY from the kernel.

PID 1 in the WSL distro has an unexpected seccomp filter attached to it by default:

wsl -d Ubuntu-22.04

$ grep -i seccomp /proc/1/status
Seccomp:        2
Seccomp_filters:        1        <<< HERE

Diagnostic Logs

No response

Another data point to help debug: In WSL kernel 5.15.83.1, I tried to dump the seccomp filter for PID 1 using the seccomp-tool, but the dump fails as follows:

$ sudo seccomp-tools dump -p 1
[ERROR] Permission denied - ptrace seccomp_get_filter failed
        PTRACE_SECCOMP_GET_FILTER requires CAP_SYS_ADMIN

Though it reports a permission error, the process doing the call has CAP_SYS_ADMIN (via sudo). The same occurs when trying to dump seccomp filters for any other process in the WSL distro (i.e., can't dump the seccomp filters).

In constrast, in WSL kernel 5.15.79.1, there is no error (and no filters are reported since there are none on PID 1):

$ sudo seccomp-tools dump -p 1
$ echo $?
0

Kelsey Steele (@kelsey-steele)

Kelsey Steele (@kelsey-steele) - do you have any idea what might be going on here?

I don't at first glance, though I'll do some investigating.

Kelsey Steele (@kelsey-steele)

Thanks Kelsey Steele (@kelsey-steele) for the help. For context, I work at Docker and came across this while doing some development work on a container runtime that uses seccomp-notify, and which we hope to support on WSL. Things were working well with WSL kernel 5.15.79.1 but broke in 5.15.83.1.

Cesar Talledo (@ctalledo)

Thank you for all the information and I appreciate your patience Cesar Talledo (@ctalledo)! I didn't have luck reproducing this on my current machine running the 5.15.83 WSL kernel, though I am on Win11 and may have some other differences on my environment. I have on my queue to test with a Win10 instance tomorrow.

Some questions that may help me reproduce:
Are you running on a x86 or arm64 machine?
What version of WSL are you running?
When you went back to 5.15.79, did you also change WSL versions or only the kernel?
Have you created a new WSL Ubuntu instance to see if the issue also appears there?

I did get a new WSL kernel release out on Friday (5.15.90.1). If you have the ability and time to test that kernel, let me know if the issue persists. Can always be hopeful this was something caused upstream and already fixed. :)

Kelsey Steele (@kelsey-steele)

Hi Kelsey Steele (@kelsey-steele), thanks for taking a closer look, much appreciated.

Are you running on a x86 or arm64 machine?

x86.

What version of WSL are you running?

C:\> wsl --version
WSL version: 1.1.2.0
Kernel version: 5.15.83.1
WSLg version: 1.0.49
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.1250

NOTE: I used the Windows Insider program to download the latest WSL kernel (5.15.83.1) a couple of weeks ago.

When you went back to 5.15.79, did you also change WSL versions or only the kernel?

I didn't go back to 5.15.79; rather, my Windows dev machine had 5.15.79.1 and things were working perfectly. I then upgraded to 5.15.83.1 and noticed the problem. I then tried on another Windows machine with 5.15.79.1 and things worked there too.

Have you created a new WSL Ubuntu instance to see if the issue also appears there?

The issue is present in all distros on the machine where the WSL kernel is 5.15.83.1 (Ubuntu distro, docker-desktop's custom distro, etc.) I believe that's because it's a kernel level problem and all distros are sharing the same kernel.

I did get a new WSL kernel release out on Friday (5.15.90.1). If you have the ability and time to test that kernel, let me know if the issue persists. Can always be hopeful this was something caused upstream and already fixed. :)

Sure, let me give that a try and report.

Thanks again!

Kelsey Steele (@kelsey-steele)

I did get a new WSL kernel release out on Friday (5.15.90.1). If you have the ability and time to test that kernel, let me know if the issue persists.

Kelsey Steele (@kelsey-steele): how do I update the WSL kernel to that release? I tried wsl.exe --update but it says I am already using the latest kernel (5.15.83.1). Thanks.

Cesar Talledo (@ctalledo)

Cesar Talledo (@ctalledo) thank you for the additional info!

The WSL2 kernel gets released on the WSL2 kernel repo first and then will be included in the next WSL release. Currently we're in that stage where the new kernel is so far only released on the WSL2 kernel repo. Here's the steps you can follow to boot with the 5.15.90 WSL kernel:

Clone the WSL2 Kernel Repo
Make sure you're on the 'linux-msft-wsl-5.15.y' branch or checkout the 'linux-msft-wsl-5.15.90.1' tag
Follow the build instructions in the WSL2 kernel README
After building, you will find your new kernel image inside the WSL2 tree at 'arch/x86/boot/bzImage'
copy this to your windows files for easy access. i.e. $ cp arch/x86/boot/bzImage /mnt/c/Users/$USERNAME/5.15.90.1-wsl

Add the new kernel to your .wslconfig file:

 [wsl2]
 kernel=C:\\Users\\$USERNAME\\5.15.90.1-wsl

Run 'wsl --shutdown' inside powershell
Restart your WSL instance and verify new kernel is being used: $ uname -r

These are the same steps you'd use to boot with a custom or upstream kernel on x86 machines. Just make sure to build any kernel you want to use with the config file from WSL2 (can be found in the WSL2 tree under Microsoft/config-wsl).

Let me know if you have any questions or unable to take these steps. Hoping I'll be able to reproduce on my side today so I can poke at things.

Kelsey Steele (@kelsey-steele)

Hi Kelsey Steele (@kelsey-steele), thanks for the detailed instructions to upgrade the WSL kernel, super clear and easy to follow.

I updated my WSL kernel to 5.15.90.1, but unfortunately still hit the same issue:

C:\Users\Cesar> wsl -d Ubuntu-22.04

cesar@xps15:/mnt/c/Users/Cesar$ uname -a
Linux xps15 5.15.90.1-microsoft-standard-WSL2+ #1 SMP Tue Feb 7 10:58:54 PST 2023 x86_64 x86_64 x86_64 GNU/Linux

cesar@xps15:/mnt/c/Users/Cesar$ grep -i seccomp /proc/1/status
Seccomp:     2
Seccomp_filters: 1        <<< HERE: why does the init process have a seccomp filter on it?

As a result, when I try to run a container with Docker Desktop on WSL, using this new runtime that uses seccomp-notify, it fails with:

$ docker run -it --rm alpine
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: container_linux.go:429: starting container process caused: init_linux.go:631: loading seccomp notification rules caused: error loading seccomp filter into kernel: device or resource busy: unknown.

Could you double check on your side if /proc/1/status on your WSL kernel 5.15.90.1 shows a seccomp filter on it?

Thanks!

Thinking out loud, I wonder if the init process in the WSL distro (PID 1) is inserting that seccomp filter. I assume it's a custom init process for WSL, is the code for it available so I can take a look? I believe also that the init process is the same for all WSL distros correct?

Cesar Talledo (@ctalledo)

Cesar Talledo (@ctalledo) I was able to reproduce this. This requires WSL 1.1.0 or later to reproduce.

I tested rolling the kernel back to 5.15.79.1 while on WSL 1.1.0 and 1.1.2 which did not resolve the problem. However, once I rolled the WSL version back to 1.0.3, the seccomp filter on PID 1 reports as expected (with 0) with each kernel (5.15.79.1 - 5.15.90.1)

I believe your thinking is on the right path. I also believe the portion of code that needs to be examined is closed and needs to be checked on our side, though I very much appreciate all your help to debug! For the question if the init process is the same for all WSL distros, that escapes a bit out of my current knowledge. Ben Hillis (@benhillis) do you have an answer for this?

Ben Hillis (@benhillis) I see in the WSL 1.1.0 release notes there is a change "Use seccomp in localhost relay". Can I get help investigating that patch to see if it's linked here?

Cesar Talledo (@ctalledo) for a temporary fix, I'd advise rolling WSL back to 1.0.3:

uninstall WSL (not the distros, just "Windows Subsystem for Linux").
Download the msixbundle from the 1.0.3 release page.
Install by running the downloaded file or in powershell run $ Add-AppxPackage -Path "Path to msixbundle"

edit: your distro installs should be ok throughout this process, though it's always smart to backup first just in case. You can use "wsl --export <Distro> <FileName>" to accomplish that. :)

Ben Hillis (@benhillis) if there's a more appropriate route for downgrading WSL, please correct me. :)

Kelsey Steele (@kelsey-steele)

Hi Kelsey Steele (@kelsey-steele), thanks for the update, glad you were able to reproduce it.

This requires WSL 1.1.0 or later to reproduce.

Got it; I can confirm that my machine where it fails has WSL 1.1.2.0, while the machine where it passes has WSL 1.0.3.0.

I believe your thinking is on the right path. I also believe the portion of code that needs to be examined is closed and needs to be checked on our side

Got it, thanks for letting me know.

To help a bit more:

The problem is that when installing a seccomp-notify filter into the WSL kernel we are getting back EBUSY. Per seccomp(2), this occurs when there is prior seccomp-notify filter already installed for the process:

       EBUSY  While installing a new filter, the
              SECCOMP_FILTER_FLAG_NEW_LISTENER flag was specified, but a
              previous filter had already been installed with that flag.

I suspect that PID 1 in the WSL distros is already under such a filter (as evidenced by the output of grep -i seccomp /proc/1/status above) and since a process inherits seccomp filters from its parent, it means all processes in the WSL distro have the filter applied. Thus when our container runtime inside WSL tries to insert another seccomp-notify filter for the container, it gets an EBUSY.

I'd advise rolling WSL back to 1.0.3.

Thanks; this will work for me, but since we are planning to have Docker Desktop on WSL use seccomp-notify very soon, we are hoping for a fix so that our customers can get to use it without having to worry about what version of WSL they have.

Thanks again for the help so far!

Craig Loewen (@craigloewen-msft)

Hi Craig Loewen (@craigloewen-msft), Ben Hillis (@benhillis), sorry to bother but any feedback on my prior comment? Thanks!

Issue still happens with WSL 2.5.1 (Linux 6.6.75).

Cesar Talledo (@ctalledo)

hello Cesar Talledo (@ctalledo), sorry for the delay following up
the presence of the seccomp filters is expected when networkingMode=mirrored

can you please share more details about the Docker scenario/s affected by this

thanks

Cătălin Emil Fetoiu (@CatalinFetoiu)

Hi Cătălin Emil Fetoiu (@CatalinFetoiu) thanks for the response.

can you please share more details about the Docker scenario/s affected by this

Sure; Docker (and possibly other runtimes too) sometimes use a seccomp notify filter to trap system calls inside a container.

The Linux kernel only allows one such filter per process. And filters are inherited by child processes.

Turns out that when networkingMode=mirrored is active, apparently WSL inserts a seccomp notify filter on PID 1 of the WSL distro. That filter is inherited by all processes in the distro (since they are all descendants of PID 1), and therefore it's not possible to insert seccomp notify filters from within the distro (doing son returns EBUSY).

Ideally, we are hoping a WSL distro behaves much like a VM, where there are no seccomp filters on PID 1.

FYI we had this same problem in the past with WSL (original description of this PR), but the WSL developers were able to fix it and remove the seccomp notify filter from PID 1. However it appears to still be occurring when the mirrored networking mode is enabled unfortunately.

Cesar Talledo (@ctalledo)

Cesar Talledo (@ctalledo) thanks for the additional context about the issue

currently the mirrored mode requires the seccomp filters in order to enable inbound connectivity to WSL (an external machine or the host talking to a server in WSL). it's used to intercept bind system calls

do the the Docker scenarios that are affected by this require inbound network connectivity to WSL? if not, we can consider having this configurable via wslconfig - this way outbound network connectivity will always work, but inbound network connectivity could be disabled and the seccomp filters removed

cc Keith Horton (@keith-horton) Blue (@OneBlue)

Cătălin Emil Fetoiu (@CatalinFetoiu)

Hi Cătălin Emil Fetoiu (@CatalinFetoiu), apologies for the delayed reply.

currently the mirrored mode requires the seccomp filters in order to enable inbound connectivity to WSL (an external machine or the host talking to a server in WSL). it's used to intercept bind system calls

I see ... it's a problem though because since WSL is adding the seccomp-notify filter on PID 1 and all child processes inherit that, no other process within the WSL distro can use such a filter. That's a problem for Docker Desktop and other solutions such as LXD that also use seccomp-notify filters to create more secure containers within WSL.

do the the Docker scenarios that are affected by this require inbound network connectivity to WSL?

The Docker scenarios that use seccomp notify filters are for increased container security, and are totally orthogonal to the networking config the user desires. That is, some users will want to enable inbound connectivity to WSL while at the same time enjoying the more secure Docker containers.

Question: is there a way the inbound connectivity functionality can be done without seccomp-notify, or at least without seccomp-notify on PID 1?

Hi,
Just checking if there will be a fix for this use case without un-setting networkingMode=mirrored, specifically for customers using Docker Desktop, WSL2 backend with networkingMode=mirrored. Is there workaround without disabling mirrored network mode and without disabled enhanced container isolation on Docker Desktop? Thank you.

docs: add WSL2 support plan

A bug from 2023, nice!

Same problem here. My configs:
wsl --version

WSL version: 2.6.3.0
Kernel version: 6.6.87.2-1
WSLg version: 1.0.71
MSRDC version: 1.2.6353
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26100.7462

fix(agent): name the WSL interop trap instead of failing at extraction (

fix(wsl2): start without Unix-socket mediation on WSL2

feat(roe): retire the nftables path — OpenShell is the only network b…

Navigation Menu

Repository navigation

Inserting seccomp notify filter in WSL kernel 5.15.83.1 fails with EBUSY #9548

Version

WSL Version

Kernel Version

Distro Version

Other Software

Repro Steps

Expected Behavior

Actual Behavior

Diagnostic Logs

17 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Inserting seccomp notify filter in WSL kernel 5.15.83.1 fails with EBUSY #9548

Description

Version

WSL Version

Kernel Version

Distro Version

Other Software

Repro Steps

Expected Behavior

Actual Behavior

Diagnostic Logs

Activity

ctalledo commented on Jan 27, 2023

benhillis commented on Feb 1, 2023

kelsey-steele commented on Feb 3, 2023

ctalledo commented on Feb 3, 2023

kelsey-steele commented on Feb 7, 2023

ctalledo commented on Feb 7, 2023

ctalledo commented on Feb 7, 2023

kelsey-steele commented on Feb 7, 2023

ctalledo commented on Feb 7, 2023

ctalledo commented on Feb 7, 2023

kelsey-steele commented on Feb 8, 2023

ctalledo commented on Feb 8, 2023

17 remaining items

ctalledo commented on Feb 3, 2025

felipecrs commented on Mar 13, 2025

CatalinFetoiu commented on Mar 13, 2025

ctalledo commented on Mar 13, 2025

CatalinFetoiu commented on Mar 14, 2025

ctalledo commented on Mar 21, 2025

karman-docker commented on Feb 17, 2026

qdrddr commented on Mar 31, 2026

sergioprates commented on Apr 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions