CVE-2022-49049
published 2025-02-26CVE-2022-49049: In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix panic when growing a memfd_secret When one tries to grow an existing…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.25%
16.8th percentile
In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix panic when growing a memfd_secret
When one tries to grow an existing memfd_secret with ftruncate, one gets
a panic [1]. For example, doing the following reliably induces the
panic:
fd = memfd_secret();
ftruncate(fd, 10);
ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
strcpy(ptr, "123456789");
munmap(ptr, 10);
ftruncate(fd, 20);
The basic reason for this is, when we grow with ftruncate, we call down
into simple_setattr, and then truncate_inode_pages_range, and eventually
we try to zero part of the memory. The normal truncation code does this
via the direct map (i.e., it calls page_address() and hands that to
memset()).
For memfd_secret though, we specifically don't map our pages via the
direct map (i.e. we call set_direct_map_invalid_noflush() on every
fault). So the address returned by page_address() isn't useful, and
when we try to memset() with it we panic.
This patch avoids the panic by implementing a custom setattr for
memfd_secret, which detects resizes specifically (setting the size for
the first time works just fine, since there are no existing pages to try
to zero), and rejects them with EINVAL.
One could argue growing should be supported, but I think that will
require a significantly more lengthy change. So, I propose a minimal
fix for the benefit of stable kernels, and then perhaps to extend
memfd_secret to support growing in a separate patch.
[1]:
BUG: unable to handle page fault for address: ffffa0a889277028
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060
Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
RIP: 0010:memset_erms+0x9/0x10
Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.17.6-1 (bookworm) | linux 5.17.6-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 < b6d17c67885a5624e96eb30c4178c65eea8374bf | b6d17c67885a5624e96eb30c4178c65eea8374bf |
| linux | linux | >= 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 < 9d3b877daf805fed29be8f61aa3d0ea37df82c7b | 9d3b877daf805fed29be8f61aa3d0ea37df82c7b |
| linux | linux | >= 1507f51255c9ff07d75909a84e7c0d7f3c4b2f49 < f9b141f93659e09a52e28791ccbaf69c273b8e92 | f9b141f93659e09a52e28791ccbaf69c273b8e92 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.17.6-1 | 5.17.6-1 |
| linux | linux_kernel | >= 0 < 5.17.6-1 | 5.17.6-1 |
| linux | linux_kernel | >= 0 < 5.17.6-1 | 5.17.6-1 |
| linux | linux_kernel | >= 5.14 < 5.15.35 | 5.15.35 |
| linux | linux_kernel | >= 5.16 < 5.17.4 | 5.17.4 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: mm/secretmem: fix panic when growing a memfd_secret
vendor_redhat·2025-02-26·CVSS 5.5
CVE-2022-49049 [MEDIUM] kernel: mm/secretmem: fix panic when growing a memfd_secret
kernel: mm/secretmem: fix panic when growing a memfd_secret
In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix panic when growing a memfd_secret
When one tries to grow an existing memfd_secret with ftruncate, one gets
a panic [1]. For example, doing the following reliably induces the
panic:
fd = memfd_secret();
ftruncate(fd, 10);
ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
strcpy(ptr, "123456789");
munmap(ptr, 10);
ftruncate(fd, 20);
The basic reason for this is, when we grow with ftruncate, we call down
into simple_setattr, and then truncate_inode_pages_range, and eventually
we try to zero part of the memory. The normal truncation code does this
via the direct map (i.e., it calls page_address() and hands that to
memset()).
For memfd
Debian
CVE-2022-49049: linux - In the Linux kernel, the following vulnerability has been resolved: mm/secretme...
vendor_debian·2022·CVSS 5.5
CVE-2022-49049 [MEDIUM] CVE-2022-49049: linux - In the Linux kernel, the following vulnerability has been resolved: mm/secretme...
In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix panic when growing a memfd_secret When one tries to grow an existing memfd_secret with ftruncate, one gets a panic [1]. For example, doing the following reliably induces the panic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20); The basic reason for this is, when we grow with ftruncate, we call down into simple_setattr, and then truncate_inode_pages_range, and eventually we try to zero part of the memory. The normal truncation code does this via the direct map (i.e., it calls page_address() and hands that to memset()). For memfd_secret though, we specifically don't map our pages via the d
GHSA
GHSA-5265-p799-mv2x: In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix panic when growing a memfd_secret
When one tries to grow an ex
ghsa_unreviewed·2025-04-16
CVE-2022-49049 [MEDIUM] GHSA-5265-p799-mv2x: In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix panic when growing a memfd_secret
When one tries to grow an ex
In the Linux kernel, the following vulnerability has been resolved:
mm/secretmem: fix panic when growing a memfd_secret
When one tries to grow an existing memfd_secret with ftruncate, one gets
a panic [1]. For example, doing the following reliably induces the
panic:
fd = memfd_secret();
ftruncate(fd, 10);
ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
strcpy(ptr, "123456789");
munmap(ptr, 10);
ftruncate(fd, 20);
The basic reason for this is, when we grow with ftruncate, we call down
into simple_setattr, and then truncate_inode_pages_range, and eventually
we try to zero part of the memory. The normal truncation code does this
via the direct map (i.e., it calls page_address() and hands that to
memset()).
For memfd_secret though, we specifically don't map our pages vi
OSV
CVE-2022-49049: In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix panic when growing a memfd_secret When one tries to grow an exis
osv·2025-02-26·CVSS 5.5
CVE-2022-49049 [MEDIUM] CVE-2022-49049: In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix panic when growing a memfd_secret When one tries to grow an exis
In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix panic when growing a memfd_secret When one tries to grow an existing memfd_secret with ftruncate, one gets a panic [1]. For example, doing the following reliably induces the panic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20); The basic reason for this is, when we grow with ftruncate, we call down into simple_setattr, and then truncate_inode_pages_range, and eventually we try to zero part of the memory. The normal truncation code does this via the direct map (i.e., it calls page_address() and hands that to memset()). For memfd_secret though, we specifically don't map our pages via the d
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2025-02-26
Published