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? thanks, greg k-h
