lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 6 Jul 2022 21:09:01 +0800 From: bingjingc <bingjingc@...ology.com> To: josef@...icpanda.com, dsterba@...e.com, clm@...com, linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org Cc: bingjingc@...ology.com, robbieko@...ology.com, bxxxjxxg@...il.com Subject: [PATCH 0/2] btrfs: send: fix a bug that sending a link command on existing file path From: BingJing Chang <bingjingc@...ology.com> btrfs_ioctl_send processes recorded btrfs_keys in a defined order. (First, we process a btrfs_key with a samller objectid. If btrfs_keys have the same objectid, then we compare their types and offsets accordingly.) However, reference paths for an inode can be stored in either BTRFS_INODE_REF_KEY btrfs_keys or BTRFS_INODE_EXTREF_KEY btrfs_keys. And due to the limitation of the helper function - iterate_inode_ref, we can only iterate the entries of ONE btrfs_inode_ref or btrfs_inode_extref. That is, there must be a bug in processing the same reference paths, which are stored in different ways. Please see the second commit for the details. bingjingc (2): btrfs: send: introduce recorded_ref_alloc and recorded_ref_free btrfs: send: fix a bug that sending a link command on existing file path fs/btrfs/send.c | 194 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 180 insertions(+), 14 deletions(-) -- 2.37.0
Powered by blists - more mailing lists