CVE-2022-50334
Vulnérabilité non évaluée dans Linux (Linux)
Description
In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param() Syzkaller reports a null-ptr-deref bug as follows: ====================================================== KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380 [...] Call Trace: <TASK> vfs_parse_fs_param fs/fs_context.c:148 [inline] vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129 vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191 generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 do_new_mount fs/namespace.c:3036 [inline] path_mount+0x12de/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] </TASK> ====================================================== According to commit "vfs: parse: deal with zero length string value", kernel will set the param->string to null pointer in vfs_parse_fs_string() if fs string has zero length. Yet the problem is that, hugetlbfs_parse_param() will dereference the param->string, without checking whether it is a null pointer. To be more specific, if hugetlbfs_parse_param() parses an illegal mount parameter, such as "size=,", kernel will constructs struct fs_parameter with null pointer in vfs_parse_fs_string(), then passes this struct fs_parameter to hugetlbfs_parse_param(), which triggers the above null-ptr-deref bug. This patch solves it by adding sanity check on param->string in hugetlbfs_parse_param().
Gravité et risque d'exploitation
CVE-2022-50334 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.16 %, ce qui la place devant 4.7 % des CVE référencées.
Que faire ?
- Vérifiez si Linux (versions <=6.1.*, <965e8f8ae0f642b5528f5a82b7bcaf15a659d5bd, 0, <dcd28191be9bbf307ba51a5b485773a55b0037c4, <=5.10.*, <=6.0.*, 5.4.229, 32021982a324dce93b4ae00c06213bf45fb319c8, 6.0.16, <26215b7ee923b9251f7bb12c4e5f09dc465d35f2, <5.1, <=5.4.*, <9a8862820cbf1f18dca4f3b4c289d88561b3a384, <fa71639873518e3587632ae58e25e4a96b57fa90, 5.1, <f2207145693ae5697a7b59e2add4b92f9e5b0e3c, 5.10.163, <=*, <=5.15.*, 6.1.2, 6.2, 5.15.86) est présent sur votre parc.
- Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
- À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
- Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.
Références
- https://git.kernel.org/stable/c/fa71639873518e3587632ae58e25e4a96b57fa90
- https://git.kernel.org/stable/c/dcd28191be9bbf307ba51a5b485773a55b0037c4
- https://git.kernel.org/stable/c/9a8862820cbf1f18dca4f3b4c289d88561b3a384
- https://git.kernel.org/stable/c/965e8f8ae0f642b5528f5a82b7bcaf15a659d5bd
- https://git.kernel.org/stable/c/f2207145693ae5697a7b59e2add4b92f9e5b0e3c
- https://git.kernel.org/stable/c/26215b7ee923b9251f7bb12c4e5f09dc465d35f2
