> On Nov 28, 2023, at 2:09 PM, Kent Overstreet <[email protected]> > wrote: > > !-------------------------------------------------------------------| > This Message Is From an External Sender > > |-------------------------------------------------------------------! > > On Tue, Nov 28, 2023 at 10:04:02PM +0000, Nick Terrell wrote: >> Hi Kent, >> >> I see in the bcachefs compression code this comment [0]: >> >> Additionally, the ZSTD code seems to have a bug where it will >> write just past the end of the buffer - so subtract a fudge >> factor (7 bytes) from the dst buffer size to account for >> that. >> >> This is very unexpected, as zstd is extensively fuzzed for these types of >> bugs. >> It doesn’t look like bcachefs is using zstd in a way that would trigger a >> unique >> code path, so my first suspicion is that there is a bug in the way that >> bcachefs >> is calling zstd. >> >> I spent some time trying to reproduce the issue by calling zstd in the same >> way >> that bcachefs called zstd when the workaround was landed, but so far haven’t >> been successful in triggering the bug. >> >> If you can provide a reproducer, I will look into the issue further. If you >> can >> provide the input data, the size of the output buffer used, and the >> parameters >> used (or the level & estimated source size used to derive the parameters), I >> will definitely be able to debug the issue, and get it fixed if it is a >> problem with >> zstd. >> >> Best, >> Nick Terrell >> >> [0] >> https://github.com/torvalds/linux/blob/v6.7-rc3/fs/bcachefs/compress.c#L588 > > Sorry, just saw the subject - I haven't looked at the end of buffer bug > in quite awhile, that was many kernel releases ago. It's entirely > possible it's been fixed since then (but it was a nasty source of memory > corruption for a good while).
If you do ever happen by a reproducer, let me know. The zstd code in the kernel hasn’t been significantly updated since October 2022, so nothing has changed on that side. I will spend a bit more time trying to reproduce the issue, since any out of bounds write is a top priority issue for us, but I really think the issue isn’t in zstd, since this is widely used code that is also heavily fuzzed for this exact scenario. > I never had a reproducer for it, only tracked it down through end user > reports. Do you happen to have a link to these reports? Best, Nick Terrell
