aboutsummaryrefslogtreecommitdiff
path: root/sound/virtio
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2026-10-27 08:01:30 -1000
committerLinus Torvalds <torvalds@linux-foundation.org>2026-10-27 08:01:30 -1000
commit62c457528529cdcfa32bc52b331ceca10f3937b6 (patch)
tree996f24181b89b02cbc2afcbe74888590877e9639 /sound/virtio
parentc60ebc3208b9ce1d8915318347962f7ce1dbd07d (diff)
parent503b65da9a7e5447d91222f62399522f2f62a0fa (diff)
Merge tag 'vfs-7.4-rc1.keyring' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfsHEADmaster
Pull vfs keyring updates from Christian Brauner: "The kernel has two keyrings that userspace fills with X.509 certificates at boot: .fs-verity for fs-verity built-in signatures and .dm-verity for dm-verity root hash signatures. Neither is linked into any process keyring. Hence, request_key() and KEYCTL_SEARCH can't find them. The only way for userspace to identify them is to read their serial number out of /proc/keys. That is not just a large file often the names can also be reused and appear multiple times which allows forging these keyrings. This adds two fixed special key ids, KEY_SPEC_DM_VERITY_KEYRING and KEY_SPEC_FS_VERITY_KEYRING next to KEY_SPEC_BPF_KEYRING. The latter went in through bpf-next this merge window. lookup_user_key() resolves the fixed key ids to the two keyrings. So userspace can add a dm-verity (fixed keyring id: -10) certificate with keyctl padd asymmetric "" -10 < cert.der and seal the keyring with keyctl restrict_keyring -10 without looking anything up first" * tag 'vfs-7.4-rc1.keyring' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: Documentation: keys: document IDs added since KEY_SPEC_REQKEY_AUTH_KEY keys: add KEY_SPEC_FS_VERITY_KEYRING keys: add KEY_SPEC_DM_VERITY_KEYRING
Diffstat (limited to 'sound/virtio')
0 files changed, 0 insertions, 0 deletions