Re: [PATCH] btrfs-progs: fix and prevent off-by-one bug when calling strncpy_null()

[David Sterba <dsterba@suse.cz>]

On Tue, Feb 17, 2026 at 08:51:37AM +1030, Qu Wenruo wrote:
> [BUG]
> There is a bug report that with asan enabled, "btrfs device stat
> --offline" will trigger the following out-of-boundary write error:
> 
> =================================================================
> ==4929==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7da0fd9e6100 at pc 0x7f90ff11ae55 bp 0x7ffcd98b97f0 sp 0x7ffcd98b8f98
> WRITE of size 1025 at 0x7da0fd9e6100 thread T0
>     #0 0x7f90ff11ae54 in strncpy /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_interceptors.cpp:628
>     #1 0x55ed2020e8ab in strncpy_null common/string-utils.c:62
>     #2 0x55ed202ad500 in get_fs_info_offline cmds/device.c:798
>     #3 0x55ed202ade4a in cmd_device_stats cmds/device.c:895
>     #4 0x55ed2011a4fb in cmd_execute cmds/commands.h:126
>     #5 0x55ed2011ae55 in handle_command_group /home/adam/btrfs-progs/btrfs.c:184
>     #6 0x55ed2011a4fb in cmd_execute cmds/commands.h:126
>     #7 0x55ed2011bc61 in main /home/adam/btrfs-progs/btrfs.c:469
>     #8 0x7f90fec27634  (/usr/lib/libc.so.6+0x27634) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d)
>     #9 0x7f90fec276e8 in __libc_start_main (/usr/lib/libc.so.6+0x276e8) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d)
>     #10 0x55ed2011a3d4 in _start (/home/adam/btrfs-progs/btrfs+0x873d4) (BuildId: 3a69cb43ff4e39c3dbc079d8086fb9082f21490a)
> 
> 0x7da0fd9e6100 is located 0 bytes after 4096-byte region [0x7da0fd9e5100,0x7da0fd9e6100)
> allocated by thread T0 here:
>     #0 0x7f90ff120cb5 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
>     #1 0x55ed202ad012 in get_fs_info_offline cmds/device.c:777
>     #2 0x55ed202ade4a in cmd_device_stats cmds/device.c:895
>     #3 0x55ed2011a4fb in cmd_execute cmds/commands.h:126
>     #4 0x55ed2011ae55 in handle_command_group /home/adam/btrfs-progs/btrfs.c:184
>     #5 0x55ed2011a4fb in cmd_execute cmds/commands.h:126
>     #6 0x55ed2011bc61 in main /home/adam/btrfs-progs/btrfs.c:469
>     #7 0x7f90fec27634  (/usr/lib/libc.so.6+0x27634) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d)
>     #8 0x7f90fec276e8 in __libc_start_main (/usr/lib/libc.so.6+0x276e8) (BuildId: 2f722da304c0a508c891285e6840199c35019c8d)
>     #9 0x55ed2011a3d4 in _start (/home/adam/btrfs-progs/btrfs+0x873d4) (BuildId: 3a69cb43ff4e39c3dbc079d8086fb9082f21490a)
> 
> SUMMARY: AddressSanitizer: heap-buffer-overflow common/string-utils.c:62 in strncpy_null
> Shadow bytes around the buggy address:
>   0x7da0fd9e5e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7da0fd9e5f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7da0fd9e5f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7da0fd9e6000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x7da0fd9e6080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x7da0fd9e6100:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x7da0fd9e6180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x7da0fd9e6200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x7da0fd9e6280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x7da0fd9e6300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
>   0x7da0fd9e6380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
> ==4929==ABORTING
> 
> [CAUSE]
> Inside get_fs_info_offline(), we call strncpy_null() to fill
> di_args[i].path, but that path array is only BTRFS_DEVICE_PATH_NAME_MAX
> sized, and we're passing "BTRFS_DEVICE_PATH_NAME_MAX + 1" as size.
> 
> This will make strncpy_null() to always set the last byte to 0, which
> triggers the above access beyond boundary.
> 
> [FIX]
> For that specific caller, just use the size of that array.
> We can not change the definition of btrfs_ioctl_dev_info_args, as that
> is part of the user API.
> But most other structures have already include one extra byte to handle
> the terminating zero.
> 
> And since we're here, replace all strncpy_null() to use sizeof() as its
> size parameter when the target is a fixed size array, to prevent similar
> problems from happening.
> 
> Most call sites are already doing that, but there are still several
> sites using open-coded sizes.
> 
> Issue: #1088
> Signed-off-by: Qu Wenruo <wqu@suse.com>

Added to devel, thanks.