linux-kernel - Re: OCFS2: [ocfs2_rename:1688 ERROR: status = -39] with four syscalls on fresh FS image

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] [day] [month] [year] [list]

Date:   Sun, 4 Nov 2018 11:48:33 +0300
From:   Anatoly Trosinenko <anatoly.trosinenko@...il.com>
To:     viro@...iv.linux.org.uk
Cc:     Mark Fasheh <mark@...heh.com>, Joel Becker <jlbec@...lplan.org>,
        ocfs2-devel@....oracle.com, linux-kernel@...r.kernel.org
Subject: Re: OCFS2: [ocfs2_rename:1688 ERROR: status = -39] with four syscalls
 on fresh FS image

Oops, excuse me, looks like it really logs every error to dmesg. And
what about NULL dereferences on corrupted images: should they be
reported at all and if yes, publicly or privately? On one hand, OCFS2
by design operates remote images, on the other hand, these images are
most probably served from some trusted source.

Best regards
Anatoly

вс, 4 нояб. 2018 г. в 10:53, Al Viro <viro@...iv.linux.org.uk>:
>
> On Sun, Nov 04, 2018 at 10:37:34AM +0300, Anatoly Trosinenko wrote:
> > Hello,
> >
> > When fuzzing OCFS2, I got an ERROR message in dmesg output with
> > several syscalls on completely fresh, uncrafted FS image. From this
> > https://oss.oracle.com/pipermail/ocfs2-devel/2012-August/008683.html
> > it looks like ERROR messages are indicating some unexpected conditions
> > in the driver code, is it right? If so, here it how to reproduce it
> > with kvm-xfstests:
> >
> > 1) Checkout latest torvalds/master (tested with commit 71e56028), copy
> > x86_64-config-4.14 from fstests to .config, `make olddefconfig`,
> > enable CONFIG_FS then OCFS2 and compile
> > 2) Create fresh OCFS2 image:
> > $ fallocate -l 256M ocfs2
> > $ mkfs.ocfs2 -L test --fs-features=local ./ocfs2
> > $ mv ocfs2 /tmp/kvm-xfstests-$USER/ # mkfs.ocfs2 seems to not operate
> > on tmpfs that can be mounted on /tmp
> > 3) gcc --static ocfs2.c -o /tmp/kvm-xfstests-$USER/repro
> > 4) Inside the ./kvm-xfstests shell
> > root@...-xfstests:~# mount /vtmp
> > root@...-xfstests:~# mount /vtmp/ocfs2 /mnt
> > [   17.168634] JBD2: Ignoring recovery information on journal
> > [   17.173903] ocfs2: Mounting device (7,0) on (node local, slot 0)
> > with ordered data mode.
> > root@...-xfstests:~# /vtmp/repro
> > [   20.597145] (repro,368,1):ocfs2_rename:1688 ERROR: status = -39
>
> That would be -ENOTEMPTY...
>
> > root@...-xfstests:~#
> >
> > Best regards
> > Anatoly
>
> > #include <sys/stat.h>
> > #include <sys/types.h>
> > #include <unistd.h>
> > #include <stdio.h>
> >
> > int main()
> > {
> >   mkdir("/mnt/xyz", 0x700);
> >   mkdir("/mnt/abc", 0x700);
> >   symlink("/mnt", "/mnt/xyz/1");
> >   rename("/mnt/abc", "/mnt/xyz");
>
> ... and this would certainly warrant that - the victim is not empty, indeed.
> AFAICS, ocfs2_rename() yells on _any_ error it's about to return.  Including
> -EMLINK, etc.