CVE-2022-48689
published 2024-05-03CVE-2022-48689: In the Linux kernel, the following vulnerability has been resolved: tcp: TX zerocopy should not sense pfmemalloc status We got a recent syzbot report [1]…
PriorityP430high7CVSS 3.1
AVLACHPRLUINSUCHIHAH
EPSS
0.19%
9.2th percentile
In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse
of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers,
using page_is_pfmemalloc() is moot, and possibly could give
false positives.
There has been attempts to make page_is_pfmemalloc() more robust,
but not using it in the first place in this context is probably better,
removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 ("net: introduce
__skb_fill_page_desc_noacc") as a prereq.
Race is more probable after commit c07aea3ef4d4
("mm: add a signature in struct page") because page_is_pfmemalloc()
is now using low order bit from page->lru.next, which can change
more often than page->index.
Low order bit should never be set for lru.next (when used as an anchor
in LRU list), so KCSAN report is mostly a false positive.
Backporting to older kernel versions seems not necessary.
[1]
BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag
write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:
__list_add include/linux/list.h:73 [inline]
list_add include/linux/list.h:88 [inline]
lruvec_add_folio include/linux/mm_inline.h:105 [inline]
lru_add_fn+0x440/0x520 mm/swap.c:228
folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246
folio_batch_add_and_move mm/swap.c:263 [inline]
folio_add_lru+0xf1/0x140 mm/swap.c:490
filemap_add_folio+0xf8/0x150 mm/filemap.c:948
__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981
pagecache_get_page+0x26/0x190 mm/folio-compat.c:104
grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116
ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988
generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738
ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270
ext4_file_write_iter+0x2e3/0x1210
call_write_iter include/linux/fs.h:2187 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x468/0x760 fs
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.19.11-1 (bookworm) | linux 5.19.11-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= c07aea3ef4d4076f18f567b98ed01e082e02ed51 < 8527c9a6bf8e54fef0a8d3d7d8874a48c725c915 | 8527c9a6bf8e54fef0a8d3d7d8874a48c725c915 |
| linux | linux | >= c07aea3ef4d4076f18f567b98ed01e082e02ed51 < 6730c48ed6b0cd939fc9b30b2d621ce0b89bea83 | 6730c48ed6b0cd939fc9b30b2d621ce0b89bea83 |
| linux | linux | >= c07aea3ef4d4076f18f567b98ed01e082e02ed51 < 3261400639463a853ba2b3be8bd009c2a8089775 | 3261400639463a853ba2b3be8bd009c2a8089775 |
| linux | linux_kernel | >= 0 < 5.19.11-1 | 5.19.11-1 |
| linux | linux_kernel | >= 0 < 5.19.11-1 | 5.19.11-1 |
| linux | linux_kernel | >= 0 < 5.19.11-1 | 5.19.11-1 |
| linux | linux_kernel | >= 5.14 < 5.15.68 | 5.15.68 |
| linux | linux_kernel | >= 5.16 < 5.19.9 | 5.19.9 |
CVSS provenance
nvdv3.17.0HIGHCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.0HIGH
vendor_debian7.0HIGH
vendor_redhat7.0HIGH
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.
OSV
CVE-2022-48689: In the Linux kernel, the following vulnerability has been resolved: tcp: TX zerocopy should not sense pfmemalloc status We got a recent syzbot report
osv·2024-05-03·CVSS 7.0
CVE-2022-48689 [HIGH] CVE-2022-48689: In the Linux kernel, the following vulnerability has been resolved: tcp: TX zerocopy should not sense pfmemalloc status We got a recent syzbot report
In the Linux kernel, the following vulnerability has been resolved: tcp: TX zerocopy should not sense pfmemalloc status We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths. Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives. There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles. Note to stable teams : You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq. Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.nex
GHSA
GHSA-93vx-p2jx-wj6m: In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot repor
ghsa_unreviewed·2024-05-03
CVE-2022-48689 [HIGH] CWE-362 GHSA-93vx-p2jx-wj6m: In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot repor
In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse
of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers,
using page_is_pfmemalloc() is moot, and possibly could give
false positives.
There has been attempts to make page_is_pfmemalloc() more robust,
but not using it in the first place in this context is probably better,
removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 ("net: introduce
__skb_fill_page_desc_noacc") as a prereq.
Race is more probable after commit c07aea3ef4d4
("mm: add a signature in struct page") because page_is_pfmemalloc()
is now using low order bit from page->
Red Hat
kernel: tcp: TX zerocopy should not sense pfmemalloc status
vendor_redhat·2024-05-03·CVSS 7.0
CVE-2022-48689 [HIGH] kernel: tcp: TX zerocopy should not sense pfmemalloc status
kernel: tcp: TX zerocopy should not sense pfmemalloc status
In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse
of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers,
using page_is_pfmemalloc() is moot, and possibly could give
false positives.
There has been attempts to make page_is_pfmemalloc() more robust,
but not using it in the first place in this context is probably better,
removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 ("net: introduce
__skb_fill_page_desc_noacc") as a prereq.
Race is more probable after commit c07aea3ef4d4
("mm: add a signature in struct page") because page_
Debian
CVE-2022-48689: linux - In the Linux kernel, the following vulnerability has been resolved: tcp: TX zer...
vendor_debian·2022·CVSS 7.0
CVE-2022-48689 [HIGH] CVE-2022-48689: linux - In the Linux kernel, the following vulnerability has been resolved: tcp: TX zer...
In the Linux kernel, the following vulnerability has been resolved: tcp: TX zerocopy should not sense pfmemalloc status We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths. Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives. There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles. Note to stable teams : You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq. Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.nex
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915
2024-05-03
Published