github-starred/firejail
2
0
Fork 0
mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00
Code Issues 531 Projects Packages Wiki Activity Actions 6

[GH-ISSUE #4208] Issue introduced in glibc 2.33 could lead to perpetual spin in firejail arp code #2578

New issue
Closed
opened 2026-05-05 09:14:55 -06:00 by gitea-mirror · 7 comments
gitea-mirror commented 2026-05-05 09:14:55 -06:00
Owner
Copy link

Originally created by @szaydel on GitHub (Apr 22, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4208

This is a bit of an unusual bug report, because while it is exposed by firejail effectively spinning indefinitely, but is a direct consequence of a seemingly small regression introduced in glibc. This is the bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27706. What we observed is that we no longer reach timeouts in select calls (which at least in our testing was using pselect6 system call) in the while (1) loop here: https://github.com/netblue30/firejail/blob/master/src/firejail/arp.c#L198, which means the terminating condition is never reached and as a consequence firejail appears to be stuck there forever, making no progress. This is the patch for this problem: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cedbf6d5f3f70ca911176de87d6e453eeab4b7a1 which is seemingly going to be in 2.34 and backported to 2.33. My colleague validated this on 2.33 where we first observed this problem. He also installed ubuntu 21.04 today just to see if the same will happen there, because it is shipping with glibc 2.33, and indeed, he confirmed the problem exists there as well. Effectively, what we are seeing is that the timeout value is not getting updated, and as a consequence the terminating condition is never met. We thought it would be good to report it here, because a) this may happen to someone else, and b) perhaps this implementation should be given another consideration.

Expected for this command to exit after a little while, which reliably happens with glibc < 2.33.

$ time sudo ./src/fnet/fnet printif scan
Interface        MAC                IP               Mask             Status
lo                                  127.0.0.1        255.0.0.0        UP
eth0             xx:xx:xx:xx:xx:xx  xx.xx.xx.xx      255.255.252.0    UP
<output omitted>
real	0m4.066s
user	0m0.010s
sys	0m0.019s

However, with glibc == 2.33 this ends-up running indefinitely, which is not the expected behaviour.

Regards, Sam.

Originally created by @szaydel on GitHub (Apr 22, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4208 This is a bit of an unusual bug report, because while it is exposed by firejail effectively spinning indefinitely, but is a direct consequence of a seemingly small regression introduced in glibc. This is the bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27706. What we observed is that we no longer reach timeouts in `select` calls (which at least in our testing was using `pselect6` system call) in the `while (1)` loop here: https://github.com/netblue30/firejail/blob/master/src/firejail/arp.c#L198, which means the terminating condition is never reached and as a consequence firejail appears to be stuck there forever, making no progress. This is the patch for this problem: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cedbf6d5f3f70ca911176de87d6e453eeab4b7a1 which is seemingly going to be in 2.34 and backported to 2.33. My colleague validated this on 2.33 where we first observed this problem. He also installed ubuntu 21.04 today just to see if the same will happen there, because it is shipping with glibc 2.33, and indeed, he confirmed the problem exists there as well. Effectively, what we are seeing is that the timeout value is not getting updated, and as a consequence the terminating condition is never met. We thought it would be good to report it here, because a) this may happen to someone else, and b) perhaps this implementation should be given another consideration. Expected for this command to exit after a little while, which reliably happens with `glibc < 2.33`. ``` $ time sudo ./src/fnet/fnet printif scan Interface MAC IP Mask Status lo 127.0.0.1 255.0.0.0 UP eth0 xx:xx:xx:xx:xx:xx xx.xx.xx.xx 255.255.252.0 UP <output omitted> real 0m4.066s user 0m0.010s sys 0m0.019s ``` However, with `glibc == 2.33` this ends-up running indefinitely, which is not the expected behaviour. Regards, Sam.
gitea-mirror commented 2026-05-05 09:14:58 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Jun 10, 2021):

Can we close here?

<!-- gh-comment-id:858442934 --> @rusty-snake commented on GitHub (Jun 10, 2021): Can we close here?
gitea-mirror commented 2026-05-05 09:14:59 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Jun 11, 2021):

@szaydel commented on Apr 22:

This is a bit of an unusual bug report, because while it is exposed by
firejail effectively spinning indefinitely, but is a direct consequence of a
seemingly small regression introduced in glibc. This is the bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=27706. What we observed is
that we no longer reach timeouts in select calls (which at least in our
testing was using pselect6 system call) in the while (1) loop here:
https://github.com/netblue30/firejail/blob/master/src/firejail/arp.c#L198,
which means the terminating condition is never reached and as a consequence
firejail appears to be stuck there forever, making no progress. This is the
patch for this problem:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cedbf6d5f3f70ca911176de87d6e453eeab4b7a1
which is seemingly going to be in 2.34 and backported to 2.33. My colleague
validated this on 2.33 where we first observed this problem. He also
installed ubuntu 21.04 today just to see if the same will happen there,
because it is shipping with glibc 2.33, and indeed, he confirmed the problem
exists there as well.

For reference, this is the current bug status:

  • Status: RESOLVED FIXED
  • Modified: 2021-04-28 10:20 UTC

The patch appears to have landed on the "release/2.33" branch:

But it seems that there hasn't been any new release in the 2.33 series.

Effectively, what we are seeing is that the timeout value is not getting
updated, and as a consequence the terminating condition is never met. We
thought it would be good to report it here, because a) this may happen to
someone else

I see; thanks for reporting.

and b) perhaps this implementation should be given another consideration.

Do you mean in firejail's arp code? Feel free to suggest improvements.

<!-- gh-comment-id:859311858 --> @kmk3 commented on GitHub (Jun 11, 2021): @szaydel commented on Apr 22: > This is a bit of an unusual bug report, because while it is exposed by > firejail effectively spinning indefinitely, but is a direct consequence of a > seemingly small regression introduced in glibc. This is the bug: > https://sourceware.org/bugzilla/show_bug.cgi?id=27706. What we observed is > that we no longer reach timeouts in `select` calls (which at least in our > testing was using `pselect6` system call) in the `while (1)` loop here: > https://github.com/netblue30/firejail/blob/master/src/firejail/arp.c#L198, > which means the terminating condition is never reached and as a consequence > firejail appears to be stuck there forever, making no progress. This is the > patch for this problem: > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=cedbf6d5f3f70ca911176de87d6e453eeab4b7a1 > which is seemingly going to be in 2.34 and backported to 2.33. My colleague > validated this on 2.33 where we first observed this problem. He also > installed ubuntu 21.04 today just to see if the same will happen there, > because it is shipping with glibc 2.33, and indeed, he confirmed the problem > exists there as well. For reference, this is the current bug status: * Status: RESOLVED FIXED * Modified: 2021-04-28 10:20 UTC The patch appears to have landed on the "release/2.33" branch: * <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3e9ca60a580e2b6854cd5314ebb0866a1f387ca8> * <https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/release/2.33/master> But it seems that there hasn't been any new release in the 2.33 series. > Effectively, what we are seeing is that the timeout value is not getting > updated, and as a consequence the terminating condition is never met. We > thought it would be good to report it here, because a) this may happen to > someone else I see; thanks for reporting. > and b) perhaps this implementation should be given another consideration. Do you mean in firejail's arp code? Feel free to suggest improvements.
gitea-mirror commented 2026-05-05 09:15:00 -06:00
Author
Owner
Copy link

@ghost commented on GitHub (Jun 11, 2021):

$ pacman -Q glibc

glibc 2.33-5

$ ./src/firejail/firejail --version

firejail version 0.9.66rc1

Compile time support:
	- always force nonewprivs support is disabled
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- output logging is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

$ time sudo ./src/fnet/fnet printif scan

Interface        MAC                IP               Mask             Status
lo                                  127.0.0.1        255.0.0.0        UP    
wlp2s0           xx:xx:xx:xx:xx:xx  <redacted>    255.255.255.0    UP    
   Network scan:
   xx:xx:xx:xx:xx:xx	<redacted>
tun0             xx:xx:xx:xx:xx:xx  <redacted>         255.255.255.0    UP    

real	0m6,766s
user	0m0,033s
sys	0m0,028s

This is Arch Linux, cannot reproduce with firejail compiled from git master. Command exits reliably. I'm not sure but it seems glibc on Arch Linux does not carry the patch you reference (cfr. the latest PKGBUILD changes).
What firejail version are you seeing this on?

<!-- gh-comment-id:859410544 --> @ghost commented on GitHub (Jun 11, 2021): $ `pacman -Q glibc` ``` glibc 2.33-5 ``` $ `./src/firejail/firejail --version` ``` firejail version 0.9.66rc1 Compile time support: - always force nonewprivs support is disabled - AppArmor support is enabled - AppImage support is enabled - chroot support is enabled - D-BUS proxy support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - firetunnel support is enabled - networking support is enabled - output logging is enabled - overlayfs support is disabled - private-home support is enabled - private-cache and tmpfs as user enabled - SELinux support is disabled - user namespace support is enabled - X11 sandboxing support is enabled ``` $ `time sudo ./src/fnet/fnet printif scan` ``` Interface MAC IP Mask Status lo 127.0.0.1 255.0.0.0 UP wlp2s0 xx:xx:xx:xx:xx:xx <redacted> 255.255.255.0 UP Network scan: xx:xx:xx:xx:xx:xx <redacted> tun0 xx:xx:xx:xx:xx:xx <redacted> 255.255.255.0 UP real 0m6,766s user 0m0,033s sys 0m0,028s ``` This is Arch Linux, cannot reproduce with firejail compiled from git master. Command exits reliably. I'm not sure but it seems glibc on Arch Linux does not carry the patch you reference (cfr. the latest [PKGBUILD](https://github.com/archlinux/svntogit-packages/commit/524fb49dd61f364fddcaacb589dd3dc11fc23b11#diff-3e341d2d9c67be01819b25b25d5e53ea3cdf3a38d28846cda85a195eb9b7203a) changes). What firejail version are you seeing this on?
gitea-mirror commented 2026-05-05 09:15:01 -06:00
Author
Owner
Copy link

@kmk3 commented on GitHub (Jun 11, 2021):

(Offtopic)

$ pacman -Q glibc

glibc 2.33-5

The console info string can be used for shell commands and their
output. Example:

```console
$ pacman -Q glibc "foo" # comment
glibc 2.33-5
```

Output:

$ pacman -Q glibc "foo" # comment
glibc 2.33-5

I think that it applies syntax highlighting only on the command line, but not
on the output (other than making it all blue, that is).

<!-- gh-comment-id:859441074 --> @kmk3 commented on GitHub (Jun 11, 2021): (Offtopic) > $ `pacman -Q glibc` > ``` > glibc 2.33-5 > ``` The [`console`][1] [info string][2] can be used for shell commands and their output. Example: ```console $ pacman -Q glibc "foo" # comment glibc 2.33-5 ``` Output: ```console $ pacman -Q glibc "foo" # comment glibc 2.33-5 ``` I think that it applies syntax highlighting only on the command line, but not on the output (other than making it all blue, that is). [1]: https://github.com/github/linguist/blob/757b173b34db14bc23c7b53a15252628add4f815/lib/linguist/languages.yml#L5438 [2]: https://spec.commonmark.org/0.29/#info-string
gitea-mirror commented 2026-05-05 09:15:02 -06:00
Author
Owner
Copy link

@szaydel commented on GitHub (Jun 14, 2021):

@glitsj16 - I am fairly sure that at the time I reported this, firejail was built from current master. I will have to see if I can repro.

<!-- gh-comment-id:860295240 --> @szaydel commented on GitHub (Jun 14, 2021): @glitsj16 - I am fairly sure that at the time I reported this, `firejail` was built from current master. I will have to see if I can repro.
gitea-mirror commented 2026-05-05 09:15:03 -06:00
Author
Owner
Copy link

@rusty-snake commented on GitHub (Aug 4, 2021):

Can we close here?

<!-- gh-comment-id:892575862 --> @rusty-snake commented on GitHub (Aug 4, 2021): Can we close here?
gitea-mirror commented 2026-05-05 09:15:04 -06:00
Author
Owner
Copy link

@szaydel commented on GitHub (Aug 5, 2021):

Yeah, sorry I have been too busy lately to look into this. I think this glibc issue has been addressed upstream anyway at this point, and so it is perhaps not meaningful to keep this open. I will do some investigation when I have some time, and if there is a reason, I can re-open. Thanks @rusty-snake !

<!-- gh-comment-id:893118462 --> @szaydel commented on GitHub (Aug 5, 2021): Yeah, sorry I have been too busy lately to look into this. I think this glibc issue has been addressed upstream anyway at this point, and so it is perhaps not meaningful to keep this open. I will do some investigation when I have some time, and if there is a reason, I can re-open. Thanks @rusty-snake !
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
serialize_remounts_v2
landlock_v4
landlock
release-0.9.64
release-0.9.62
gitlab_ci
LTSbase
fred_ctests
docs
0.9.80
0.9.80-rc1
0.9.78
0.9.76
0.9.76-rc4
0.9.76-rc3
0.9.76-rc2
0.9.76-rc1
0.9.74
landlock-split
0.9.72
0.9.72rc1
0.9.70
0.9.68
0.9.68rc1
0.9.66
0.9.66rc1
0.9.64.4
0.9.64.2
0.9.64
0.9.64rc1
0.9.62.4
0.9.62.2
0.9.62
0.9.56.2-LTS
0.9.60
0.9.60-rc1
0.9.58.2
0.9.58
0.9.58-rc1
0.9.56-LTS-release
0.9.56-LTS
0.9.56
0.9.56-rc1
0.9.54
0.9.54-rc2
0.9.54-rc1
0.9.52
0.9.38.12
0.9.50
0.9.50-rc1
0.9.48
0.9.46
0.9.46-rc1
0.9.44.10
0.9.44.8
0.9.44.6
0.9.38.10
0.9.44.4
0.9.38.8
0.9.44.2
0.9.44
0.9.44-rc1
0.9.38.4
0.9.42
0.9.42-rc2
0.9.38.2
0.9.42-rc1
disable-globalcfg
0.9.40
0.9.40-rc1
0.9.38
0.9.38-rc1
0.9.36
0.9.36-rc1
0.9.34
0.9.34-rc1
0.9.32
0.9.32-rc1
0.9.30
0.9.30-rc1
Labels
Clear labels   
LTS merge

   
LTS merge

   
bug

   
bug

   
converted-to-discussion

   
doc-todo

   
documentation

   
duplicate

   
enhancement

   
file-transfer

   
firecfg

   
firejail-in-firejail

   
firetools

   
graphics

   
help wanted

   
information_old

   
installation

   
invalid

   
modif

   
moved

   
needinfo

   
networking

   
notabug

   
notourbug

   
old-version

   
overlayfs

   
packaging

   
profile-request

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question_old

   
removal

   
runtime-permissions

   
sandbox-ipc

   
security

   
stale

   
wiki

   
wiki

   
wontfix

   
wordpress

   
workaround
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2578
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?