[PATCH 6.12] bcachefs: avoid truncating fiemap extent length

[PATCH 6.12] bcachefs: avoid truncating fiemap extent length

[Mikhail Dmitrichenko]

No upstream commit exists for this patch.

bkey sizes are stored in sectors as u32, while fiemap reports byte
lengths as u64. Shifting k.k->size before widening performs the
conversion in 32 bits, so an extent of 4 GiB or larger can wrap before
it is passed to fiemap_fill_next_extent().

Compute the byte length after casting the sector count to u64 and reuse
it for all bch2_fill_extent() cases.

The same issue was fixed in bcachefs-tools, but there is no Linux
upstream commit to backport to 6.12. The affected 6.12 implementation lives
in fs/bcachefs/fs.c, while the bcachefs-tools fix touches
fs/bcachefs/vfs/fiemap.c.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Link: https://lore.kernel.org/linux-bcachefs/20260610105547.129545-1-mdmitrichenko@astralinux.ru/
Link: https://evilpiepirate.org/git/bcachefs-tools.git/commit/?id=6d9a895ed00d4b3868312df93253d2a817b0c6a3
Signed-off-by: Mikhail Dmitrichenko <mdmitrichenko@astralinux.ru>
---
 fs/bcachefs/fs.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fs/bcachefs/fs.c b/fs/bcachefs/fs.c
index a41d0d8a2f7b..0dc2466de3f9 100644
--- a/fs/bcachefs/fs.c
+++ b/fs/bcachefs/fs.c
@@ -1184,6 +1184,8 @@ static int bch2_fill_extent(struct bch_fs *c,
 			    struct fiemap_extent_info *info,
 			    struct bkey_s_c k, unsigned flags)
 {
+	u64 len = (u64)k.k->size << 9;
+
 	if (bkey_extent_is_direct_data(k.k)) {
 		struct bkey_ptrs_c ptrs = bch2_bkey_ptrs_c(k);
 		const union bch_extent_entry *entry;
@@ -1212,7 +1214,7 @@ static int bch2_fill_extent(struct bch_fs *c,
 			ret = fiemap_fill_next_extent(info,
 						bkey_start_offset(k.k) << 9,
 						offset << 9,
-						k.k->size << 9, flags|flags2);
+						len, flags | flags2);
 			if (ret)
 				return ret;
 		}
@@ -1221,13 +1223,13 @@ static int bch2_fill_extent(struct bch_fs *c,
 	} else if (bkey_extent_is_inline_data(k.k)) {
 		return fiemap_fill_next_extent(info,
 					       bkey_start_offset(k.k) << 9,
-					       0, k.k->size << 9,
+					       0, len,
 					       flags|
 					       FIEMAP_EXTENT_DATA_INLINE);
 	} else if (k.k->type == KEY_TYPE_reservation) {
 		return fiemap_fill_next_extent(info,
 					       bkey_start_offset(k.k) << 9,
-					       0, k.k->size << 9,
+					       0, len,
 					       flags|
 					       FIEMAP_EXTENT_DELALLOC|
 					       FIEMAP_EXTENT_UNWRITTEN);
-- 
2.43.0

Re: [PATCH 6.12] bcachefs: avoid truncating fiemap extent length

[Sasha Levin]

On Thu, Jul 03, 2026 at 02:48:13PM +0300, Mikhail Dmitrichenko wrote:
> No upstream commit exists for this patch.
>
> bkey sizes are stored in sectors as u32, while fiemap reports byte
> lengths as u64. Shifting k.k->size before widening performs the
> conversion in 32 bits, so an extent of 4 GiB or larger can wrap before
> it is passed to fiemap_fill_next_extent().

Thanks for the patch, happy to take it if we can get an ack from the bcachefs
maintainers.

-- 
Thanks,
Sasha

Re: [PATCH 6.12] bcachefs: avoid truncating fiemap extent length

[Kent Overstreet]

On Fri, Jul 03, 2026 at 10:05:22PM -0400, Sasha Levin wrote:
> On Thu, Jul 03, 2026 at 02:48:13PM +0300, Mikhail Dmitrichenko wrote:
> > No upstream commit exists for this patch.
> >
> > bkey sizes are stored in sectors as u32, while fiemap reports byte
> > lengths as u64. Shifting k.k->size before widening performs the
> > conversion in 32 bits, so an extent of 4 GiB or larger can wrap before
> > it is passed to fiemap_fill_next_extent().
> 
> Thanks for the patch, happy to take it if we can get an ack from the bcachefs
> maintainers.
> 
> -- 
> Thanks,
> Sasha

Ack

Re: [PATCH 6.12] bcachefs: avoid truncating fiemap extent length

[Sasha Levin]

On Sat, Jul 04, 2026 at 09:49:11AM -0500, Kent Overstreet wrote:
>On Fri, Jul 03, 2026 at 10:05:22PM -0400, Sasha Levin wrote:
>> Thanks for the patch, happy to take it if we can get an ack from the bcachefs
>> maintainers.
>
>Ack

Queued for 6.12, thanks!

-- 
Thanks,
Sasha