On Mon, Aug 15, 2022 at 1:36 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Aug 15, 2022 at 06:56:55PM +0800, 许嘉诚 wrote: > > Hi developers, > > > > We may found a flaw in the fs module which can lead to UAF write or DoS. > > We would appreciate a CVE ID if this is a security issue. > > As our documentation states, us at security@xxxxxxxxxx do not assign > CVEs or deal with them at all. > > > > > HEAD commit: 3d7cb6b04c3f Linux-5.19 > > git tree: upstream > > console output:https://drive.google.com/file/d/1PoH9PUdMilsrKtq1oGHu_shM3dggNFAB/view?usp=sharing > > kernel config: https://drive.google.com/file/d/1wgIUDwP5ho29AM-K7HhysSTfWFpfXYkG/view?usp=sharing > > syz repro: https://drive.google.com/file/d/19N1Xh8TVoSUr_2J8j-bWXktL21SvRx_9/view?usp=sharing > > C reproducer: https://drive.google.com/file/d/1R1rYseY7JBDCSfLAP4pjSCoMVgkr7l5b/view?usp=sharing > > > > Description > > In alloc_inode, inode_init_always could return -NOMEM if > > security_inode_alloc fails. In its error handling, i_callback and > > nilfs_free_inode will be called. However, because inode->i_private is > > not initialized due to the failure of security_inode_alloc, the function > > nilfs_is_metadata_file_inode can return true and nilfs_mdt_destroy will > > > > > > be executed to lead to GPF bug. > > > > > > > > > > Someone found the similar problem: https://groups.google.com/g/syzkaller-bugs/c/z2WroC3_BSw. > > Great, can you work on this in public on that thread then? Have you > tested the proposed patch that is provided there to see if it solves it > or not? > > > Fix this bug by moving the assignment of inode->i_private before security_inode_alloc. > > That's what the existing patch looks to do, does that work? > > And again, as this is public, why notify us and not just work to solve > this in public with the developers involved? > Hi all, this email was sent to security@xxxxxxxxxx, where the emails are supposed to remain undisclosed in a private email list with curated participants, but it was also sent to the public mailing lists syzkaller@xxxxxxxxxxxxxxxx and linux-nilfs@xxxxxxxxxxxxxxx. So the whole communication is already public and disclosed. I guess there are really no measures needed now for anyone to keep anything further "secret due to security" and all efforts can be simply put in understanding the reported issue, the known patch and the next steps in the usual public channels. Just to add to Greg's advice, it was public from the beginning, so there really was not the need to have security@xxxxxxxxxx in the loop. I would like to understand which statements in the kernel's patch submission guidelines got you to report to security@xxxxxxxxxx. Can you point to those parts of the documentation? Then, we can think about how to improve those and see if that improvement helps others avoid such potential process issues in the future. Best regards, Lukas
