I am trying to squash the kernel's peculiar behaviour of implicitly enabling sealing on MFD_NOEXEC_SEAL. dbus-broker is one of the affected programs, but as noted below, only the test suite would break, normal operations wouldn't. At least as far as I can tell.
Newer Linux kernels do not unset F_SEAL_SEAL when MFD_NOEXEC_SEAL is supplied to memfd_create(). Currently, misc_memfd() has a workaround for this peculiarity of the kernel, however, this workaround will break.
Avoid the breakage by checking if the kernel added F_SEAL_SEAL, and only try to add it if it is not already present.
Note that this kernel uAPI change does not affect dbus-broker's normal operations since it never attempts to create a memfd with MFD_NOEXEC_SEAL and without MFD_ALLOW_SEALING. Only the test suite would be broken on newer kernels without this change.
I am trying to squash the kernel's peculiar behaviour of implicitly enabling sealing on
MFD_NOEXEC_SEAL
.dbus-broker
is one of the affected programs, but as noted below, only the test suite would break, normal operations wouldn't. At least as far as I can tell.Newer Linux kernels do not unset
F_SEAL_SEAL
whenMFD_NOEXEC_SEAL
is supplied tomemfd_create()
. Currently,misc_memfd()
has a workaround for this peculiarity of the kernel, however, this workaround will break.Avoid the breakage by checking if the kernel added
F_SEAL_SEAL
, and only try to add it if it is not already present.Note that this kernel uAPI change does not affect dbus-broker's normal operations since it never attempts to create a memfd with
MFD_NOEXEC_SEAL
and withoutMFD_ALLOW_SEALING
. Only the test suite would be broken on newer kernels without this change.v2: https://lore.kernel.org/linux-mm/20240524033933.135049-1-jeffxu@google.com/ v1: https://lore.kernel.org/linux-mm/20240513191544.94754-1-pobrn@protonmail.com/