Messages in this thread | | | From | butt3rflyh4ck <> | Date | Thu, 22 Jul 2021 10:43:10 +0800 | Subject | Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c |
| |
On Thu, Jul 22, 2021 at 1:37 AM Matthew Wilcox <willy@infradead.org> wrote: > > On Thu, Jul 22, 2021 at 01:14:06AM +0800, butt3rflyh4ck wrote: > > ms = (struct minix_super_block *) bh->b_data; /// --------------> set > > minix_super_block pointer > > sbi->s_ms = ms; > > sbi->s_sbh = bh; > > sbi->s_mount_state = ms->s_state; > > sbi->s_ninodes = ms->s_ninodes; > > sbi->s_nzones = ms->s_nzones; > > sbi->s_imap_blocks = ms->s_imap_blocks; > > sbi->s_zmap_blocks = ms->s_zmap_blocks; > > sbi->s_firstdatazone = ms->s_firstdatazone; > > sbi->s_log_zone_size = ms->s_log_zone_size; // ------------------> > > set sbi->s_log_zone_size >
> So what you're saying is that if you construct a malicious minix image, > you can produce undefined behaviour?
Yes, the attachment is a reproduction. just compile it and run.
>That's not something we're > traditionally interested in, unless the filesystem is one customarily > used for data interchange (like FAT or iso9660). >
These file systems are my fuzzing targets.
Regards, butt3rflyh4ck.
-- Active Defense Lab of Venustech
| |