linux-kernel - btrfs task hung in `lock_extent` syzbot report and CVE-2024-35784, patch series v2

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20251114194438.5694-1-kalachev@swemel.ru>
Date: Fri, 14 Nov 2025 22:44:32 +0300
From: Andrey Kalachev <kalachev@...mel.ru>
To: linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	fdmanana@...e.com,
	josef@...icpanda.com,
	dsterba@...e.com,
	stable@...r.kernel.org
Cc: kalachev@...mel.ru,
	lvc-project@...uxtesting.org
Subject: btrfs task hung in `lock_extent` syzbot report and CVE-2024-35784, patch series v2

> Hi.

> I've check c-repro [1] on 6.1.y branch and found that repro still produce
> the crash on 6.1.y. I notice that syzbot bisection result [2]
> is incorrect: indeed, the hung was fixed by upstream commit b0ad381fa769
> ("btrfs: fix deadlock with fiemap and extent locking"). Also,
> I saw CVE-2024-35784 [3][4] vulnerability, that have direct relation with that syzbot
> report. Therefore, syzbot reproducer provided additional way to check for CVE-2024-35784.
> 
> I attempted to fix CVE-2024-35784 in stable 6.1.y (over v6.1.157), and
> found that the initial fix commit b0ad381fa769 ("btrfs: fix deadlock with
> fiemap and extent locking") introduced regressions [5][6].
> IMHO here is the minimum patch series to eliminate CVE-2024-35784 from 6.1.y:
>
> b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking") (Initial fix of the CVE-2024-35784)
> a1a4a9ca77f1 ("btrfs: fix race between ordered extent completion and fiemap") (Fixes: b0ad381fa769)
> 978b63f7464a ("btrfs: fix race when detecting delalloc ranges during fiemap") (Fixes: b0ad381fa769)
> 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations") (Optimization: 978b63f7464a)
> 53e24158684b ("btrfs: set start on clone before calling copy_extent_buffer_full") (Fixes: 1cab1375ba6d)

UPD:
Fedor Pchelkin reported that the 1st patch series version cause fail in generic/561 fstest.
Backporting the patch
  418b09027743 ("btrfs: ensure fiemap doesn't race with writes when FIEMAP_FLAG_SYNC is given")
fixes that.

Updated patch series looks like this:

b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking") (Initial fix of the CVE-2024-35784)
a1a4a9ca77f1 ("btrfs: fix race between ordered extent completion and fiemap") (Fixes: b0ad381fa769)
418b09027743 ("btrfs: ensure fiemap doesn't race with writes when FIEMAP_FLAG_SYNC is given") (Fixes fail of generic/561 fstest)
978b63f7464a ("btrfs: fix race when detecting delalloc ranges during fiemap") (Fixes: b0ad381fa769)
1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations") (Optimization: 978b63f7464a)
53e24158684b ("btrfs: set start on clone before calling copy_extent_buffer_full") (Fixes: 1cab1375ba6d)

Also, in previouse cover letter I've included the wrong C-reproducer link,
the right one is:
  https://syzkaller.appspot.com/text?tag=ReproC&x=1262428c580000

Best regards,
AK

Reported-by: syzbot+f8217aae382555004877@...kaller.appspotmail.com
Reported-by: Fedor Pchelkin <pchelkin@...ras.ru>