linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Endless readdir() loop on btrfs.
@ 2023-08-12 21:52 Rob Landley
  2023-08-13 11:37 ` Filipe Manana
  0 siblings, 1 reply; 3+ messages in thread
From: Rob Landley @ 2023-08-12 21:52 UTC (permalink / raw)
  To: linux-btrfs; +Cc: enh

Would anyone like to comment on:

  https://bugzilla.kernel.org/show_bug.cgi?id=217681

which resulted from:

  https://github.com/landley/toybox/issues/306

and just got re-reported as:

  https://github.com/landley/toybox/issues/448

The issue is that modifications to the directory during a getdents()
deterministically append the modified entry to the getdents(), which means
directory traversal is never guaranteed to end, which seems like a denial of
service attack waiting to happen.

This is not a problem on ext4 or tmpfs or vfat or the various flash filesystems,
where readdir() reliably completes. This is a btrfs-specific problem.

I can try to add a CONFIG_BTRFS_BUG optional workaround comparing the dev:inode
pair of returned entries to filter out ones I've already seen, but can I
reliably stop at the first duplicate or do I have to continue to see if there's
more I haven't seen yet? (I dunno what your return order is.) If some OTHER
process is doing a "while true; do mv a b; mv b a; done" loop in a directory,
that could presumably pin any OTHER process doing a naieve readdir() loop over
that directory, hence denial of service...

Rob

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-08-13 16:41 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-12 21:52 Endless readdir() loop on btrfs Rob Landley
2023-08-13 11:37 ` Filipe Manana
2023-08-13 16:43   ` Rob Landley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).