On Mon, May 27, 2024 at 09:57:49 PM +1000, Dave Chinner wrote: > On Mon, May 27, 2024 at 03:59:07PM +0530, Chandan Babu R wrote: >> On Mon, May 27, 2024 at 07:22:49 PM +1000, Dave Chinner wrote: >> > On Mon, May 27, 2024 at 10:05:17AM +0530, Chandan Babu R wrote: >> >> >> >> [CC-ing linux-xfs mailing list] >> >> >> >> On Sat, May 25, 2024 at 12:41:19 AM +0800, lei lu wrote: >> >> > Add a check to make sure xfs_dir2_data_unused and xfs_dir2_data_entry >> >> > don't stray beyond valid memory region. >> > >> > How was this found? What symptoms did it have? i.e. How do we know >> > if we've tripped over the same problem on an older LTS/distro kernel >> > and need to backport it? >> > >> >> > Tested-by: lei lu <llfamsec@xxxxxxxxx> >> >> > Signed-off-by: lei lu <llfamsec@xxxxxxxxx> >> >> >> >> Also adding the missing RVB from Darrick, >> >> >> >> Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx> >> > >> > That's not really normal process - adding third party tags like this >> > are kinda frowned upon because there's no actual public record of >> > Darrick saying this. >> >> Ok. The patch was posted on security@xxxxxxxxxx with me on CC. Hence, I had >> decided to forward the patch to linux-xfs for any reviews from the wider >> audience. > > Ugh. More "security process" madness. Please at least tell us what > context you are forwarding issues from so we aren't left guessing at > what happened prior to the mailing list post... > > Regardless, this issue is no different to any number of > syzkaller bugs that have been reported over the past few years. > security@xxxxxxxxxx should be reserved for real security problems, > not for reporting issues found by filesystem image fuzzers that > require root permissions before the kernel can be exposed to them. > Yes, I agree. Hence, I decided on forwarding the patch to linux-xfs mailing list. However, I now realize that I should have asked the patch author to post the patch on the mailing list. I am sorry about that. >> > i.e. patches send privately should really be reposted to the public >> > list by the submitter and everyone then adds their rvb/acks, etc on >> > list themselves. >> > >> >> Sorry, I didn't know about the last part i.e. rvbs need to be added once again >> after reposting the patch. > > I'm more concerned more about having an open, verifiable process. > sobs and rvbs that stem from private discussions have no actual > value because they are not verifiable via the archives of the public > discussion on the issue. -- Chandan
