Re: [vs] KASAN: use-after-free in nilfs_mdt_destroy

Re: [vs] KASAN: use-after-free in nilfs_mdt_destroy

[Greg KH]

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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org 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

Re: [vs] KASAN: use-after-free in nilfs_mdt_destroy

[Ryusuke Konishi]

Hi,

> And again, as this is public, why notify us and not just work to solve
> this in public with the developers involved?
>
> thanks,

Thank you for reporting.

This looks like a nilfs2 specific bug rather than a vfs problem.
I'd like to send a patch that fixes this on the nilfs2 side.

Thanks,
Ryusuke Konishi

On Mon, Aug 15, 2022 at 8:36 PM Greg KH 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org 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

Re: [vs-plain] KASAN: use-after-free in nilfs_mdt_destroy

[John Haxby]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]



> On 15 Aug 2022, at 11:56, 许嘉诚 <stitch-Y5EWUtBUdg4nDS1+zs4M5A@public.gmane.org> 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.
> 

Confirming that your message made it through to linux-distros, but you haven't mentioned a date when this would be made public.  However,

> Someone found the similar problem: https://groups.google.com/g/syzkaller-bugs/c/z2WroC3_BSw.
> 
> Fix this bug by moving the assignment of inode->i_private before security_inode_alloc.

There's already a public discussion about that and if, indeed, that's the same bug then you should take this to oss-security as simply a rediscovery of an existing bug.

I'll leave it to Red Hat to decide whether to allocate a CVE number for this issue. It needs significant privileges to exploit it; the only real question is whether you could use those privileges to crash the machine anyway.

jch

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [vs-plain] KASAN: use-after-free in nilfs_mdt_destroy

[butt3rflyh4ck]

Hi, there is a patch for this issue.
https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91-m1nqm0VisMk@public.gmane.orgu.cn/T/#u


On Tue, Aug 16, 2022 at 3:36 PM John Haxby <john.haxby-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>
>
>
> > On 15 Aug 2022, at 11:56, 许嘉诚 <stitch-Y5EWUtBUdg7F11Dp+j+f1g@public.gmane.orgn> 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.
> >
>
> Confirming that your message made it through to linux-distros, but you haven't mentioned a date when this would be made public.  However,
>
> > Someone found the similar problem: https://groups.google.com/g/syzkaller-bugs/c/z2WroC3_BSw.
> >
> > Fix this bug by moving the assignment of inode->i_private before security_inode_alloc.
>
> There's already a public discussion about that and if, indeed, that's the same bug then you should take this to oss-security as simply a rediscovery of an existing bug.
>
> I'll leave it to Red Hat to decide whether to allocate a CVE number for this issue. It needs significant privileges to exploit it; the only real question is whether you could use those privileges to crash the machine anyway.
>
> jch
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/8C0C088A-11A4-4D0E-93B9-CA70F0040341%40oracle.com.



-- 
Active Defense Lab of Venustech

Re: [vs] KASAN: use-after-free in nilfs_mdt_destroy

[Lukas Bulwahn]

On Mon, Aug 15, 2022 at 1:36 PM Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org and linux-nilfs-u79uwXL29TaiAVqoAR/hOA@public.gmane.org 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org in the loop.

I would like to understand which statements in the kernel's patch
submission guidelines got you to report to security-DgEjT+Ai2yi4UlQgPVntAg@public.gmane.org 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