lkml.org 
[lkml]   [2021]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: 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

    \
     
     \ /
      Last update: 2021-07-22 04:45    [W:3.592 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site