From: Josef Bacik <josef@toxicpanda.com>
To: fdmanana@kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: send: fix buffer overflow detection when copying path to cache entry
Date: Tue, 24 Sep 2024 10:41:43 -0400 [thread overview]
Message-ID: <20240924144143.GB183026@perftesting> (raw)
In-Reply-To: <ee24884b0255f717071ca932bda1ab398707d9cf.1726782272.git.fdmanana@suse.com>
On Thu, Sep 19, 2024 at 10:50:52PM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> Starting with commit c0247d289e73 ("btrfs: send: annotate struct
> name_cache_entry with __counted_by()") we annotated the variable length
> array "name" from the name_cache_entry structure with __counted_by() to
> improve overflow detection. However that alone was not correct, because
> the length of that array does not match the "name_len" field - it matches
> that plus 1 to include the nul string terminador, so that makes a
> fortified kernel think there's an overflow and report a splat like this:
>
> Sep 15 23:32:17 sdslinux1 kernel: ------------[ cut here ]------------
> Sep 15 23:32:17 sdslinux1 kernel: strcpy: detected buffer overflow: 20
> byte write of buffer size 19
> Sep 15 23:32:17 sdslinux1 kernel: WARNING: CPU: 3 PID: 3310 at
> __fortify_report+0x45/0x50
> Sep 15 23:32:17 sdslinux1 kernel: Modules linked in: nfsd auth_rpcgss
> lockd grace nfs_acl bridge stp llc bonding tls vfat fat binfmt_misc
> snd_hda_codec_hdmi intel_rapl_msr intel_rapl_common x8
> 6_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt intel_pmc_bxt
> spi_intel_platform kvm at24 mei_wdt spi_intel mei_pxp
> iTCO_vendor_support mei_hdcp btusb snd_hda_codec_realtek btbcm btinte
> l snd_hda_scodec_component i915 rapl iwlwifi snd_hda_codec_generic btrtl
> intel_cstate btmtk cec snd_hda_intel intel_uncore cfg80211
> snd_intel_dspcfg drm_buddy coretemp snd_intel_sdw_acpi bluet
> ooth ttm pcspkr snd_hda_codec rfkill snd_hda_core snd_hwdep intel_vbtn
> snd_pcm mei_me drm_display_helper snd_timer sparse_keymap i2c_i801 mei
> snd i2c_smbus lpc_ich soundcore cdc_mbim cdc_wdm cdc_ncm cdc_ether
> usbnet crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni
> polyval_generic ghash_clmulni_intel sha512_ssse3 sha256_ssse3 sha1_ssse3
> igb r8152 serio_raw i2c_algo_bit mii dca e1000e video wmi sunrpc
> Sep 15 23:32:17 sdslinux1 kernel: CPU: 3 UID: 0 PID: 3310 Comm: btrfs
> Not tainted 6.11.0-prnet #1
> Sep 15 23:32:17 sdslinux1 kernel: Hardware name: CompuLab Ltd.
> sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018
> Sep 15 23:32:17 sdslinux1 kernel: RIP: 0010:__fortify_report+0x45/0x50
> Sep 15 23:32:17 sdslinux1 kernel: Code: 48 8b 34 (...)
> Sep 15 23:32:17 sdslinux1 kernel: RSP: 0018:ffff97ebc0d6f650 EFLAGS:
> 00010246
> Sep 15 23:32:17 sdslinux1 kernel: RAX: 7749924ef60fa600 RBX:
> ffff8bf5446a521a RCX: 0000000000000027
> Sep 15 23:32:17 sdslinux1 kernel: RDX: 00000000ffffdfff RSI:
> ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8
> Sep 15 23:32:17 sdslinux1 kernel: RBP: ffff8bf548574080 R08:
> ffffffffa8c40e10 R09: 0000000000005ffd
> Sep 15 23:32:17 sdslinux1 kernel: R10: 0000000000000004 R11:
> ffffffffa8c70e10 R12: ffff8bf551eef400
> Sep 15 23:32:17 sdslinux1 kernel: R13: 0000000000000000 R14:
> 0000000000000013 R15: 00000000000003a8
> Sep 15 23:32:17 sdslinux1 kernel: FS: 00007fae144de8c0(0000)
> GS:ffff8bf84e780000(0000) knlGS:0000000000000000
> Sep 15 23:32:17 sdslinux1 kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> Sep 15 23:32:17 sdslinux1 kernel: CR2: 00007fae14691690 CR3:
> 00000001027a2003 CR4: 00000000001706f0
> Sep 15 23:32:17 sdslinux1 kernel: Call Trace:
> Sep 15 23:32:17 sdslinux1 kernel: <TASK>
> Sep 15 23:32:17 sdslinux1 kernel: ? __warn+0x12a/0x1d0
> Sep 15 23:32:17 sdslinux1 kernel: ? __fortify_report+0x45/0x50
> Sep 15 23:32:17 sdslinux1 kernel: ? report_bug+0x154/0x1c0
> Sep 15 23:32:17 sdslinux1 kernel: ? handle_bug+0x42/0x70
> Sep 15 23:32:17 sdslinux1 kernel: ? exc_invalid_op+0x1a/0x50
> Sep 15 23:32:17 sdslinux1 kernel: ? asm_exc_invalid_op+0x1a/0x20
> Sep 15 23:32:17 sdslinux1 kernel: ? __fortify_report+0x45/0x50
> Sep 15 23:32:17 sdslinux1 kernel: __fortify_panic+0x9/0x10
> Sep 15 23:32:17 sdslinux1 kernel: __get_cur_name_and_parent+0x3bc/0x3c0
> Sep 15 23:32:17 sdslinux1 kernel: get_cur_path+0x207/0x3b0
> Sep 15 23:32:17 sdslinux1 kernel: send_extent_data+0x709/0x10d0
> Sep 15 23:32:17 sdslinux1 kernel: ? find_parent_nodes+0x22df/0x25d0
> Sep 15 23:32:17 sdslinux1 kernel: ? mas_nomem+0x13/0x90
> Sep 15 23:32:17 sdslinux1 kernel: ? mtree_insert_range+0xa5/0x110
> Sep 15 23:32:17 sdslinux1 kernel: ? btrfs_lru_cache_store+0x5f/0x1e0
> Sep 15 23:32:17 sdslinux1 kernel: ? iterate_extent_inodes+0x52d/0x5a0
> Sep 15 23:32:17 sdslinux1 kernel: process_extent+0xa96/0x11a0
> Sep 15 23:32:17 sdslinux1 kernel: ? __pfx_lookup_backref_cache+0x10/0x10
> Sep 15 23:32:17 sdslinux1 kernel: ? __pfx_store_backref_cache+0x10/0x10
> Sep 15 23:32:17 sdslinux1 kernel: ? __pfx_iterate_backrefs+0x10/0x10
> Sep 15 23:32:17 sdslinux1 kernel: ? __pfx_check_extent_item+0x10/0x10
> Sep 15 23:32:17 sdslinux1 kernel: changed_cb+0x6fa/0x930
> Sep 15 23:32:17 sdslinux1 kernel: ? tree_advance+0x362/0x390
> Sep 15 23:32:17 sdslinux1 kernel: ? memcmp_extent_buffer+0xd7/0x160
> Sep 15 23:32:17 sdslinux1 kernel: send_subvol+0xf0a/0x1520
> Sep 15 23:32:17 sdslinux1 kernel: btrfs_ioctl_send+0x106b/0x11d0
> Sep 15 23:32:17 sdslinux1 kernel: ? __pfx___clone_root_cmp_sort+0x10/0x10
> Sep 15 23:32:17 sdslinux1 kernel: _btrfs_ioctl_send+0x1ac/0x240
> Sep 15 23:32:17 sdslinux1 kernel: btrfs_ioctl+0x75b/0x850
> Sep 15 23:32:17 sdslinux1 kernel: __se_sys_ioctl+0xca/0x150
> Sep 15 23:32:17 sdslinux1 kernel: do_syscall_64+0x85/0x160
> Sep 15 23:32:17 sdslinux1 kernel: ? __count_memcg_events+0x69/0x100
> Sep 15 23:32:17 sdslinux1 kernel: ? handle_mm_fault+0x1327/0x15c0
> Sep 15 23:32:17 sdslinux1 kernel: ? __se_sys_rt_sigprocmask+0xf1/0x180
> Sep 15 23:32:17 sdslinux1 kernel: ? syscall_exit_to_user_mode+0x75/0xa0
> Sep 15 23:32:17 sdslinux1 kernel: ? do_syscall_64+0x91/0x160
> Sep 15 23:32:17 sdslinux1 kernel: ? do_user_addr_fault+0x21d/0x630
> Sep 15 23:32:17 sdslinux1 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e
> Sep 15 23:32:17 sdslinux1 kernel: RIP: 0033:0x7fae145eeb4f
> Sep 15 23:32:17 sdslinux1 kernel: Code: 00 48 89 (...)
> Sep 15 23:32:17 sdslinux1 kernel: RSP: 002b:00007ffdf1cb09b0 EFLAGS:
> 00000246 ORIG_RAX: 0000000000000010
> Sep 15 23:32:17 sdslinux1 kernel: RAX: ffffffffffffffda RBX:
> 0000000000000004 RCX: 00007fae145eeb4f
> Sep 15 23:32:17 sdslinux1 kernel: RDX: 00007ffdf1cb0ad0 RSI:
> 0000000040489426 RDI: 0000000000000004
> Sep 15 23:32:17 sdslinux1 kernel: RBP: 00000000000078fe R08:
> 00007fae144006c0 R09: 00007ffdf1cb0927
> Sep 15 23:32:17 sdslinux1 kernel: R10: 0000000000000008 R11:
> 0000000000000246 R12: 00007ffdf1cb1ce8
> Sep 15 23:32:17 sdslinux1 kernel: R13: 0000000000000003 R14:
> 000055c499fab2e0 R15: 0000000000000004
> Sep 15 23:32:17 sdslinux1 kernel: </TASK>
> Sep 15 23:32:17 sdslinux1 kernel: ---[ end trace 0000000000000000 ]---
> Sep 15 23:32:17 sdslinux1 kernel: ------------[ cut here ]------------
>
> Fix this by not storing the nul string terminator since we don't actually
> need it for name cache entries, this way "name_len" corresponds to the
> actual size of the "name" array. This requires marking the "name" array
> field with __nonstring and using memcpy() instead of strcpy() as
> recommended by the guidelines at:
>
> https://github.com/KSPP/linux/issues/90
>
> Reported-by: David Arendt <admin@prnet.org>
> Link: https://lore.kernel.org/linux-btrfs/cee4591a-3088-49ba-99b8-d86b4242b8bd@prnet.org/
> Fixes: c0247d289e73 ("btrfs: send: annotate struct name_cache_entry with __counted_by()")
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
next prev parent reply other threads:[~2024-09-24 14:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 21:50 [PATCH] btrfs: send: fix buffer overflow detection when copying path to cache entry fdmanana
2024-09-21 22:02 ` Wang Yugui
2024-09-22 1:10 ` Wang Yugui
2024-09-22 11:15 ` Filipe Manana
2024-09-24 14:41 ` Josef Bacik [this message]
2024-09-24 21:18 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240924144143.GB183026@perftesting \
--to=josef@toxicpanda.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox