On Mon, Oct 15, 2018 at 8:08 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote:
> 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 am not sure how exactly this should be classified. To significant
degree these "$FOO" discriminations are informational and only really
affect the data format passed in. For ioctl/write it's not really
possible to know what exactly it will do if you just open a file
(which can be a link to into an overlay mount pointing to some special
file). Sometimes we also want to specifically spoof exact fd type (or
other resource type) for a syscall. Sometimes we discover other ioctl
command constants while running an ioctl, and then we just change the
command constant but leave the data as is.
>> 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. :-)
... or paving the way to opening all of this to non-root users. Why
not if not bugs? ;)
Back to this bug, I think we should wait to see if it happens more in
future and if syzkaller can come up with a repro. If it won't happen
more (perhaps fixed by your patch), then we will close it as obsolete.
