* Re: [PATCH 6.18.y] fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0
2026-05-18 18:26 [PATCH 6.18.y] fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0 Vlad Poenaru
@ 2026-05-18 18:34 ` Joanne Koong
2026-05-18 18:50 ` Greg KH
2026-05-19 17:48 ` [PATCH 6.18.y v2] " Vlad Poenaru
2 siblings, 0 replies; 6+ messages in thread
From: Joanne Koong @ 2026-05-18 18:34 UTC (permalink / raw)
To: Vlad Poenaru
Cc: Miklos Szeredi, Breno Leitao, Josef Bacik, linux-fsdevel,
linux-kernel, stable, fuse-devel
[adding fuse-devel list to cc]
On Mon, May 18, 2026 at 11:26 AM Vlad Poenaru <vlad.wing@gmail.com> wrote:
>
> When fc->max_read is smaller than PAGE_SIZE (common on aarch64 with
> 64K base pages if the FUSE server advertises a small max_read in INIT),
> max_pages = min(fc->max_pages, fc->max_read / PAGE_SIZE) is 0, so
> cur_pages is 0 on every outer iteration.
>
> fuse_io_alloc(NULL, 0) then calls fuse_folios_alloc(0, ...), which
> calls kzalloc(0, ...) and gets back ZERO_SIZE_PTR == (void *)16.
> The "if (!ia->ap.folios)" guard in fuse_io_alloc does not catch
> ZERO_SIZE_PTR, so fuse_io_alloc happily returns an ia whose
> ap.folios is 0x10.
>
> The inner "while (pages < cur_pages)" loop runs zero times, then
> fuse_send_readpages(ia, ...) dereferences ap->folios[0] in
> folio_pos(), faulting at virtual address 0x10:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 0000000000000010
> fuse_readahead+0x14c/0x490
> read_pages+0x80/0x318
> page_cache_ra_unbounded+0x1c0/0x2b0
> page_cache_ra_order+0xb8/0x368
> page_cache_sync_ra+0x210/0x320
> filemap_get_pages+0x290/0xdb0
> generic_file_read_iter+0xd0/0x540
> fuse_file_read_iter+0x8c/0x158
> __arm64_sys_read+0x1a0/0x488
>
> addr2line on the aarch64 vmlinux maps fuse_readahead+0x14c to
> fs/fuse/file.c:897 inlined into :999, i.e. "folio_pos(ap->folios[0])"
> inside fuse_send_readpages. The faulting instruction "ldr x8, [x8]"
> loads ap->folios[0]; ap->folios was previously loaded as 0x10
> (ZERO_SIZE_PTR).
>
> Without this fix the function would also spin forever, since
> "nr_pages -= pages" makes no progress when pages stays 0; in practice
> the NULL deref masks the spin.
>
> Bail out of the outer loop if cur_pages is 0 -- there is no work we
> can issue via FUSE in this iteration, and remaining folios will be
> handled by read_pages() falling back to ->read_folio.
>
> Note: this code was rewritten in mainline by commit 4ea907108a5c
> ("fuse: use iomap for readahead"), which switched fuse_readahead to
> iomap and removed the buggy loop entirely. This patch therefore
> applies only to stable branches that still carry the pre-iomap
> readahead path.
>
> Fixes: 3eab9d7bc2f4 ("fuse: convert readahead to use folios")
> Reported-by: Breno Leitao <leitao@debian.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
> ---
> fs/fuse/file.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/fs/fuse/file.c b/fs/fuse/file.c
> index 6014d588845c..782178124512 100644
> --- a/fs/fuse/file.c
> +++ b/fs/fuse/file.c
> @@ -974,6 +974,16 @@ static void fuse_readahead(struct readahead_control *rac)
> unsigned cur_pages = min(max_pages, nr_pages);
> unsigned int pages = 0;
>
> + /*
> + * If max_pages == 0 (e.g. fc->max_read < PAGE_SIZE on a
> + * 64K-page kernel), cur_pages is 0 and we cannot make
> + * progress. Bailing here avoids passing 0 to fuse_io_alloc,
> + * which would return an ia whose ap.folios is ZERO_SIZE_PTR
> + * (0x10) -- later dereferenced by fuse_send_readpages.
> + */
> + if (!cur_pages)
> + break;
> +
> if (fc->num_background >= fc->congestion_threshold &&
> rac->ra->async_size >= readahead_count(rac))
> /*
> --
> 2.53.0-Meta
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 6.18.y] fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0
2026-05-18 18:26 [PATCH 6.18.y] fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0 Vlad Poenaru
2026-05-18 18:34 ` Joanne Koong
@ 2026-05-18 18:50 ` Greg KH
2026-05-19 17:48 ` [PATCH 6.18.y v2] " Vlad Poenaru
2 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2026-05-18 18:50 UTC (permalink / raw)
To: Vlad Poenaru
Cc: Miklos Szeredi, Joanne Koong, Breno Leitao, Josef Bacik,
linux-fsdevel, linux-kernel, stable
On Mon, May 18, 2026 at 11:26:02AM -0700, Vlad Poenaru wrote:
> When fc->max_read is smaller than PAGE_SIZE (common on aarch64 with
> 64K base pages if the FUSE server advertises a small max_read in INIT),
> max_pages = min(fc->max_pages, fc->max_read / PAGE_SIZE) is 0, so
> cur_pages is 0 on every outer iteration.
>
> fuse_io_alloc(NULL, 0) then calls fuse_folios_alloc(0, ...), which
> calls kzalloc(0, ...) and gets back ZERO_SIZE_PTR == (void *)16.
> The "if (!ia->ap.folios)" guard in fuse_io_alloc does not catch
> ZERO_SIZE_PTR, so fuse_io_alloc happily returns an ia whose
> ap.folios is 0x10.
>
> The inner "while (pages < cur_pages)" loop runs zero times, then
> fuse_send_readpages(ia, ...) dereferences ap->folios[0] in
> folio_pos(), faulting at virtual address 0x10:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 0000000000000010
> fuse_readahead+0x14c/0x490
> read_pages+0x80/0x318
> page_cache_ra_unbounded+0x1c0/0x2b0
> page_cache_ra_order+0xb8/0x368
> page_cache_sync_ra+0x210/0x320
> filemap_get_pages+0x290/0xdb0
> generic_file_read_iter+0xd0/0x540
> fuse_file_read_iter+0x8c/0x158
> __arm64_sys_read+0x1a0/0x488
>
> addr2line on the aarch64 vmlinux maps fuse_readahead+0x14c to
> fs/fuse/file.c:897 inlined into :999, i.e. "folio_pos(ap->folios[0])"
> inside fuse_send_readpages. The faulting instruction "ldr x8, [x8]"
> loads ap->folios[0]; ap->folios was previously loaded as 0x10
> (ZERO_SIZE_PTR).
>
> Without this fix the function would also spin forever, since
> "nr_pages -= pages" makes no progress when pages stays 0; in practice
> the NULL deref masks the spin.
>
> Bail out of the outer loop if cur_pages is 0 -- there is no work we
> can issue via FUSE in this iteration, and remaining folios will be
> handled by read_pages() falling back to ->read_folio.
>
> Note: this code was rewritten in mainline by commit 4ea907108a5c
> ("fuse: use iomap for readahead"), which switched fuse_readahead to
> iomap and removed the buggy loop entirely. This patch therefore
> applies only to stable branches that still carry the pre-iomap
> readahead path.
>
> Fixes: 3eab9d7bc2f4 ("fuse: convert readahead to use folios")
> Reported-by: Breno Leitao <leitao@debian.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
> ---
> fs/fuse/file.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply [flat|nested] 6+ messages in thread* [PATCH 6.18.y v2] fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0
2026-05-18 18:26 [PATCH 6.18.y] fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0 Vlad Poenaru
2026-05-18 18:34 ` Joanne Koong
2026-05-18 18:50 ` Greg KH
@ 2026-05-19 17:48 ` Vlad Poenaru
2026-05-20 0:54 ` Sasha Levin
2026-05-20 11:40 ` Breno Leitao
2 siblings, 2 replies; 6+ messages in thread
From: Vlad Poenaru @ 2026-05-19 17:48 UTC (permalink / raw)
To: stable; +Cc: gregkh, miklos, joannelkoong, linux-fsdevel, leitao
[ Upstream commit 4ea907108a5c ("fuse: use iomap for readahead") ]
The upstream fix is the iomap conversion in commit 4ea907108a5c
("fuse: use iomap for readahead"), which rewrote fuse_readahead()
entirely and removed the buggy loop along with it. That refactor
is too invasive to backport to the pre-iomap readahead path still
used by 6.18.y (and earlier stable branches), so this is a minimal,
equivalent fix to the same bug on those branches.
When fc->max_read is smaller than PAGE_SIZE (common on aarch64 with
64K base pages if the FUSE server advertises a small max_read in INIT),
max_pages = min(fc->max_pages, fc->max_read / PAGE_SIZE) is 0, so
cur_pages is 0 on every outer iteration.
fuse_io_alloc(NULL, 0) then calls fuse_folios_alloc(0, ...), which
calls kzalloc(0, ...) and gets back ZERO_SIZE_PTR == (void *)16.
The "if (!ia->ap.folios)" guard in fuse_io_alloc does not catch
ZERO_SIZE_PTR, so fuse_io_alloc happily returns an ia whose
ap.folios is 0x10.
The inner "while (pages < cur_pages)" loop runs zero times, then
fuse_send_readpages(ia, ...) dereferences ap->folios[0] in
folio_pos(), faulting at virtual address 0x10:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000010
fuse_readahead+0x14c/0x490
read_pages+0x80/0x318
page_cache_ra_unbounded+0x1c0/0x2b0
page_cache_ra_order+0xb8/0x368
page_cache_sync_ra+0x210/0x320
filemap_get_pages+0x290/0xdb0
generic_file_read_iter+0xd0/0x540
fuse_file_read_iter+0x8c/0x158
__arm64_sys_read+0x1a0/0x488
addr2line on the aarch64 vmlinux maps fuse_readahead+0x14c to
fs/fuse/file.c:897 inlined into :999, i.e. "folio_pos(ap->folios[0])"
inside fuse_send_readpages. The faulting instruction "ldr x8, [x8]"
loads ap->folios[0]; ap->folios was previously loaded as 0x10
(ZERO_SIZE_PTR).
Without this fix the function would also spin forever, since
"nr_pages -= pages" makes no progress when pages stays 0; in practice
the NULL deref masks the spin.
Bail out of the outer loop if cur_pages is 0 -- there is no work we
can issue via FUSE in this iteration, and remaining folios will be
handled by read_pages() falling back to ->read_folio.
Fixes: 3eab9d7bc2f4 ("fuse: convert readahead to use folios")
Reported-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
---
v1: https://lore.kernel.org/all/20260518182602.3107764-1-vlad.wing@gmail.com/
Changes since v1:
- Add "[ Upstream commit 4ea907108a5c ... ]" anchor.
- No code changes.
fs/fuse/file.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 6014d588845c..782178124512 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -974,6 +974,16 @@ static void fuse_readahead(struct readahead_control *rac)
unsigned cur_pages = min(max_pages, nr_pages);
unsigned int pages = 0;
+ /*
+ * If max_pages == 0 (e.g. fc->max_read < PAGE_SIZE on a
+ * 64K-page kernel), cur_pages is 0 and we cannot make
+ * progress. Bailing here avoids passing 0 to fuse_io_alloc,
+ * which would return an ia whose ap.folios is ZERO_SIZE_PTR
+ * (0x10) -- later dereferenced by fuse_send_readpages.
+ */
+ if (!cur_pages)
+ break;
+
if (fc->num_background >= fc->congestion_threshold &&
rac->ra->async_size >= readahead_count(rac))
/*
--
2.53.0-Meta
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH 6.18.y v2] fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0
2026-05-19 17:48 ` [PATCH 6.18.y v2] " Vlad Poenaru
@ 2026-05-20 0:54 ` Sasha Levin
2026-05-20 11:40 ` Breno Leitao
1 sibling, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2026-05-20 0:54 UTC (permalink / raw)
To: stable
Cc: Sasha Levin, gregkh, miklos, joannelkoong, linux-fsdevel, leitao,
Vlad Poenaru
On Tue, May 19, 2026 at 10:48:16AM -0700, Vlad Poenaru wrote:
> [ Upstream commit 4ea907108a5c ("fuse: use iomap for readahead") ]
>
> The upstream fix is the iomap conversion in commit 4ea907108a5c
> ("fuse: use iomap for readahead"), which rewrote fuse_readahead()
> entirely and removed the buggy loop along with it. That refactor
> is too invasive to backport to the pre-iomap readahead path still
> used by 6.18.y (and earlier stable branches), so this is a minimal,
> equivalent fix to the same bug on those branches.
[...]
> Fixes: 3eab9d7bc2f4 ("fuse: convert readahead to use folios")
> Reported-by: Breno Leitao <leitao@debian.org>
> Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
> Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
Queued for 6.18, thanks.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 6.18.y v2] fuse: avoid 0x10 fault in fuse_readahead when max_pages == 0
2026-05-19 17:48 ` [PATCH 6.18.y v2] " Vlad Poenaru
2026-05-20 0:54 ` Sasha Levin
@ 2026-05-20 11:40 ` Breno Leitao
1 sibling, 0 replies; 6+ messages in thread
From: Breno Leitao @ 2026-05-20 11:40 UTC (permalink / raw)
To: Vlad Poenaru; +Cc: stable, gregkh, miklos, joannelkoong, linux-fsdevel
On Tue, May 19, 2026 at 10:48:16AM -0700, Vlad Poenaru wrote:
> [ Upstream commit 4ea907108a5c ("fuse: use iomap for readahead") ]
>
> The upstream fix is the iomap conversion in commit 4ea907108a5c
> ("fuse: use iomap for readahead"), which rewrote fuse_readahead()
> entirely and removed the buggy loop along with it. That refactor
> is too invasive to backport to the pre-iomap readahead path still
> used by 6.18.y (and earlier stable branches), so this is a minimal,
> equivalent fix to the same bug on those branches.
>
> When fc->max_read is smaller than PAGE_SIZE (common on aarch64 with
> 64K base pages if the FUSE server advertises a small max_read in INIT),
> max_pages = min(fc->max_pages, fc->max_read / PAGE_SIZE) is 0, so
> cur_pages is 0 on every outer iteration.
>
> fuse_io_alloc(NULL, 0) then calls fuse_folios_alloc(0, ...), which
> calls kzalloc(0, ...) and gets back ZERO_SIZE_PTR == (void *)16.
> The "if (!ia->ap.folios)" guard in fuse_io_alloc does not catch
> ZERO_SIZE_PTR, so fuse_io_alloc happily returns an ia whose
> ap.folios is 0x10.
>
> The inner "while (pages < cur_pages)" loop runs zero times, then
> fuse_send_readpages(ia, ...) dereferences ap->folios[0] in
> folio_pos(), faulting at virtual address 0x10:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 0000000000000010
> fuse_readahead+0x14c/0x490
> read_pages+0x80/0x318
> page_cache_ra_unbounded+0x1c0/0x2b0
> page_cache_ra_order+0xb8/0x368
> page_cache_sync_ra+0x210/0x320
> filemap_get_pages+0x290/0xdb0
> generic_file_read_iter+0xd0/0x540
> fuse_file_read_iter+0x8c/0x158
> __arm64_sys_read+0x1a0/0x488
>
> addr2line on the aarch64 vmlinux maps fuse_readahead+0x14c to
> fs/fuse/file.c:897 inlined into :999, i.e. "folio_pos(ap->folios[0])"
> inside fuse_send_readpages. The faulting instruction "ldr x8, [x8]"
> loads ap->folios[0]; ap->folios was previously loaded as 0x10
> (ZERO_SIZE_PTR).
>
> Without this fix the function would also spin forever, since
> "nr_pages -= pages" makes no progress when pages stays 0; in practice
> the NULL deref masks the spin.
>
> Bail out of the outer loop if cur_pages is 0 -- there is no work we
> can issue via FUSE in this iteration, and remaining folios will be
> handled by read_pages() falling back to ->read_folio.
>
> Fixes: 3eab9d7bc2f4 ("fuse: convert readahead to use folios")
> Reported-by: Breno Leitao <leitao@debian.org>
> Reviewed-by: Joanne Koong <joannelkoong@gmail.com>
> Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
Thanks for the fix, Vlad.
Acked-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply [flat|nested] 6+ messages in thread