Affected: Linux

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+0…