linux-kernel - [PATCH 0/2] btrfs: send: fix a bug that sending a link command on existing file path

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220706130903.1661-1-bingjingc@synology.com>
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