linux-ext4 - Re: WARNING in ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Oct 2018 14:08:21 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     syzbot <syzbot+85da7ac734f7ba432ee4@...kaller.appspotmail.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        linux-ext4@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: WARNING in ext4_invalidatepage

On Mon, Oct 15, 2018 at 03:22:42PM +0200, Dmitry Vyukov wrote:
> Now that you mention EXT4_IOC_SWAP_BOOT, I think I looked at the wrong
> program, there is a subsequent one that does ioctl(0x6611) where
> 0x6611 is in fact EXT4_IOC_SWAP_BOOT. So I think it's this one:
> 
> 05:23:28 executing program 5:
> r0 = creat(&(0x7f00000001c0)='./file0\x00', 0x0)
> socketpair$unix(0x1, 0x1, 0x0, &(0x7f0000000380)={0xffffffffffffffff,
> <r1=>0xffffffffffffffff})
> write$RDMA_USER_CM_CMD_CREATE_ID(r0, &(0x7f0000000240)={0x0, 0x18,
> 0xfa00, {0x0, &(0x7f0000000200)}}, 0x20)
> ioctl$PERF_EVENT_IOC_ENABLE(r1, 0x8912, 0x400200)
> ioctl$EXT4_IOC_SETFLAGS(r0, 0x6611, &(0x7f0000000000)=0x4000)

Ah, so is it a bug in Syzkaller that it is printing
ioctl$EXT4_IOC_SETFLAGS when 0x6611 is in fact EXT4_IOC_SWAP_BOOT,
right?

> I've tried to manually reply this program and the whole log too, but
> it does not reproduce. This may be related to the fact that filesystem
> accumulates too much global state, so probably first relevant part
> happened long time ago, and then second relevant part happened later
> and triggered the warning. But just re-doing the second part does not
> reproduce the bug.

It was probably some other process racing with EXT4_IOC_SWAP_BOOT.
The patch I referenced in my previous e-mail protects against
additional scenarios where someone might be trying to punch a whole
into a file that is being swapped into the bootloader ioctl.  This
particular ioctl isn't yet being used by anyone, so it had some other
issues as well, such as not interacting well with inline_data-enabled
file systems --- not that any bootloader would be small enough that it
would fit in an inline_data inode, but we're basically proofing the
code against a malicious (or buggy) root-privileged program... such as
syzbot.  :-)

						- Ted