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_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
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.15.68, 5.19.9
- CVEs
- CVE-2022-48689
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 2 Nov 2026, 21:37 UTC · Revision 1
Source evidence
tcp: TX zerocopy should not sense pfmemalloc status
core-osv · Original sourcePublished 3 May 2024, 15:00 UTC
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
osv:CVE-2022-48689
Kernel
Fixed versions: 5.15.68, 5.19.9
Complete source record
{
"id": "eba969d1a2cd8dd321b2bce1d31aa37d5c26b0f560478db9e6968c460ac3c06e",
"url": "https://osv.dev/vulnerability/CVE-2022-48689",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "tcp: TX zerocopy should not sense pfmemalloc status",
"summary": "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",
"evidence": "osv:CVE-2022-48689",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.15.68",
"evidence": "/affected/1/ranges"
},
{
"value": "5.19.9",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "CVE-2022-48689",
"aliases": [
"CVE-2022-48689"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "c07aea3ef4d4076f18f567b98ed01e082e02ed51"
},
{
"fixed": "8527c9a6bf8e54fef0a8d3d7d8874a48c725c915"
},
{
"fixed": "6730c48ed6b0cd939fc9b30b2d621ce0b89bea83"
},
{
"fixed": "3261400639463a853ba2b3be8bd009c2a8089775"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-48689.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.14.0"
},
{
"fixed": "5.15.68"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "5.19.9"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-48689.json"
}
}
],
"modified": "2026-10-28T02:30:23.931293768Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775",
"https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83",
"https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/48xxx/CVE-2022-48689.json",
"https://nvd.nist.gov/vuln/detail/CVE-2022-48689",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/48xxx/CVE-2022-48689.json"
}
},
"related_cves": [
{
"value": "CVE-2022-48689",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 490324,
"published_at": "2024-05-03T15:00:02.083+00:00"
}