| 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
| ||
|
Message-ID: <1419827352.5162.77.camel@localhost>
Date: Sun, 28 Dec 2014 23:29:12 -0500
From: Eric Paris <eparis@...hat.com>
To: ivo welch <ivo.welch@...il.com>
Cc: Heinrich Schuchardt <xypron.glpk@....de>,
linux-kernel@...r.kernel.org
Subject: Re: fanotify bug on gdb -- hard crash
Change FAN_OPEN_PERM to FAN_OPEN
If you have any more deadlocks, please let us know. Once you understand
the difference between the two let us know if there are any more
problems...
-Eric
On Mon, 2014-12-29 at 08:13 +0800, ivo welch wrote:
>
>
> I really don't know what I am doing. however, the code is really not
> mine, but verbatim from the man-page example,
> http://man7.org/linux/man-pages/man7/fanotify.7.html . I had more
> code below my code, but had whittled down the example to illustrate
> where my system locks up.
>
>
> I wonder if there could be safeguards in the call to avoid crashing
> the system. I know fanotify is playing with fire, but should it
> incapacitate the system in this way?
>
>
> in the end, all I want to do is log each and every file-open operation
> asap. I want to do read-only probing. could someone please point me
> to a correct example or facility if the manpage is wrong.
>
>
> /iaw
>
>
>
> ----
> Ivo Welch (ivo.welch@...il.com)
> http://www.ivo-welch.info/
> J. Fred Weston Professor of Finance
> Anderson School at UCLA, C519
> Director, UCLA Anderson Fink Center for Finance and Investments
> Free Finance Textbook, http://book.ivo-welch.info/
> Editor, Critical Finance Review,
> http://www.critical-finance-review.org/
>
>
> On Mon, Dec 29, 2014 at 7:13 AM, Eric Paris <eparis@...hat.com> wrote:
> Why are you setting FAN_OPEN_PERM and then not responding to
> perm
> requests? Of course the system is going to appear locked,
> until you
> start responding to open events, remove that mark, or close
> the fanotify
> fd...
>
> -Eric
>
> On Fri, 2014-12-26 at 19:40 +0100, Heinrich Schuchardt wrote:
> > Hello Ivo,
> >
> > On 26.12.2014 15:45, ivo welch wrote:
> > > I am not a kernel developer, so forgive the intrusion.
> > >
> > > I suspect I have found either a bug in gdb (less likely)
> or a bug in
> > > fanotify (more likely). it is replicable, and the code is
> almost
> > > unchanged from the example in the fanotify man page. to
> trigger it,
> > > all an su needs to do is to step through the program below
> with gdb
> > > 7.8.1 'n' command, and linux locks up the system pretty
> hard (reboot
> > > required). I have confirmed the replicability of this
> issue on a
> > > clean arch 2014.12.01 3.17.6-1 system and on a clean
> ubuntu 14.10
> > > system, both VMs created just to check it. /iaw
> > >
> > >
> > > #define _GNU_SOURCE /* Needed to get O_LARGEFILE
> definition */
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <errno.h>
> > > #include <fcntl.h>
> > > #include <poll.h>
> > > #include <sys/fanotify.h>
> > >
> > > int main(int argc, char *argv[]) {
> > > int fd;
> > > fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT |
> FAN_NONBLOCK,
> > > O_RDONLY | O_LARGEFILE);
> > > if (fd == -1) exit(1);
> > > fprintf(stderr, "calling fanotify_mark: fd=%d\n", fd);
> > > if (fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
> FAN_OPEN_PERM |
> > > FAN_CLOSE_WRITE, -1, "/") == -1) exit(2);
> > > fprintf(stderr, "in gdb step through with 'n' for
> repeat.\n");
> > > fprintf(stderr, " (and sometimes otherwise), a ^C
> works, but a ^Z
> > > and then ^C does not.\n");
> > > }
> >
> > I was not able to reproduce your problem according to your
> description
> > with Ubuntu 14.10.
> >
> > I ran a Ubuntu 14.04 amd64 LiveImage in a VM and compiled
> your example with
> > gcc -g -o test test.c
> >
> > The gdb version in Ubuntu 14.10 is 7.4 and not 7.8.1. The
> kernel version
> > is 3.13.
> >
> > root@...ntu:/home/ubuntu/temp# gdb ./test
> > GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
> > Copyright (C) 2012 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later
> > <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and
> redistribute it.
> > There is NO WARRANTY, to the extent permitted by law. Type
> "show copying"
> > and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > For bug reporting instructions, please see:
> > <http://bugs.launchpad.net/gdb-linaro/>...
> > Reading symbols from /home/ubuntu/temp/test...done.
> > (gdb) break main
> > Breakpoint 1 at 0x400693: file test.c, line 10.
> > (gdb) run
> > Starting program: /home/ubuntu/temp/test
> > warning: no loadable sections found in added symbol-file
> system-supplied
> > DSO at 0x7ffff7ffa000
> >
> > Breakpoint 1, main (argc=1, argv=0x7fffffffe638) at
> test.c:10
> > 10 fd = fanotify_init(FAN_CLOEXEC | FAN_CLASS_CONTENT
> | FAN_NONBLOCK,
> > (gdb) n
> > 12 if (fd == -1) exit(1);
> > (gdb) n
> > 13 fprintf(stderr, "calling fanotify_mark: fd=%d\n",
> fd);
> > (gdb) n
> > calling fanotify_mark: fd=7
> > 14 if (fanotify_mark(fd, FAN_MARK_ADD |
> FAN_MARK_MOUNT,
> > FAN_OPEN_PERM |
> > (gdb) n
> > 16 fprintf(stderr, "in gdb step through with 'n' for
> repeat.\n");
> > (gdb) n
> > in gdb step through with 'n' for repeat.
> > 17 fprintf(stderr, " (and sometimes otherwise), a ^C
> works, but
> > a ^Z and then ^C does not.\n");
> > (gdb) n
> > (and sometimes otherwise), a ^C works, but a ^Z and then
> ^C does not.
> > 18 }
> > (gdb) n
> > 0x00007ffff7a3b78d in __libc_start_main () from
> > /lib/x86_64-linux-gnu/libc.so.6
> > (gdb) n
> > Single stepping until exit from function __libc_start_main,
> > which has no line number information.
> > [Inferior 1 (process 4423) exited with code 0110]
> > (gdb) n
> > The program is not being run.
> > (gdb) q
> > root@...ntu:/home/ubuntu/temp#
> >
> > >
> > > I don't know who else to tell this. I hope this report is
> useful, if
> > > someone competent can confirm it. /iaw
> >
> > Bug reports for the Linux kernel should be adressed to the
> maintainer.
> > You can find him in the MAINTAINERS file of the linux
> source.
> >
> > See
> >
> https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
> > https://bugzilla.kernel.org/
> >
> > Before reporting a bug it is worthwhile to check if the
> problem also
> > occurs with the current kernel version (as of today 3.18.1
> or 3.19-rc1).
> >
> > > PS: Is there an alternative to fanotify to avoid this? I
> want to
> > > learn of all file-open requests on a ro device.
> > > ----
> >
> > The fanotify API is the right choice. Inotify is an
> alternative but
> > requires marking all directories.
> >
> > For your task you can use the code provided at
> > https://launchpad.net/fatrace
> >
> > Best regards
> >
> > Heinrich Schuchardt
>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists