Triggered by https://lists.ipfire.org/pipermail/development/2022-June/013728.html. While commit 54bd60b67b477e5d5814293a74086dff1c21ac69 mitigates the underlying - and currently unknown - issue, /dev is not covered by it. Before the final release of Core Update 169 we should... (a) find out what component introduced this change, and if there are other parts of the core system affected in any way (b) harden the mount options of /dev, as they have been before. This is security relevant, but not a show-stopper to the testing release.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=0664b1720d2d32f01ad9b9126450e35aa4d357df
I can confirm that this patch solves the issue: [root@maverick ~]# cat /etc/os-release NAME="IPFire" VERSION="2.27" ID=ipfire VERSION_ID=2 PRETTY_NAME="IPFire 2.27 (x86_64) - core169 Development Build: next/0664b172" ANSI_COLOR="0:31" [root@maverick ~]# mount /dev/sda4 on / type ext4 (rw,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=1963708k,nr_inodes=490927,mode=755) /proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) /sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) /run on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=8192k,mode=755) none on /sys/fs/cgroup type cgroup2 (rw,relatime) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) /dev/sda1 on /boot type ext4 (rw,nosuid,nodev,noexec,relatime) /dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro) /var/lock on /var/lock type tmpfs (rw,nosuid,nodev,relatime,size=8192k) (The mount options of /boot are custom set by me to prepare hardening them for all users in Core Update 170.)
(In reply to Peter Müller from comment #1) > https://git.ipfire.org/?p=ipfire-2.x.git;a=commit; > h=0664b1720d2d32f01ad9b9126450e35aa4d357df Is this patch back ported from mainline or where did it come from?
> Is this patch back ported from mainline or where did it come from? Yes. It can be also retrieved from https://lore.kernel.org/lkml/20121120215059.GA1859@www.outflux.net/.
(In reply to Peter Müller from comment #4) > > Is this patch back ported from mainline or where did it come from? > > Yes. It can be also retrieved from > https://lore.kernel.org/lkml/20121120215059.GA1859@www.outflux.net/. Well, this isn't quite mainline. As far as I can see this patch was proposed by Kees in 2012 and did not make it into the kernel. So I would prefer to not pick up random kernel patches that did not meet the criteria of the kernel developers.
Oh, I misunderstood your question. Sorry. That patch has been added to mainline kernel on December 30, 2021: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=28f0c335dd4a1a4b44b3e6c6402825a93132e1a4 However, it does not seem to have been backported to any of the LTS kernels, at least not to 5.15.x - hope this helps.
https://blog.ipfire.org/post/ipfire-2-27-core-update-169-is-available-for-testing Bumping this straight to FIXED since the issue only appeared while mastering Core Update 169.