linux-kernel - Possible bug in inotify api

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

Date:	Thu, 21 Jul 2011 08:47:44 +0200
From:	Morten Winkler Jørgensen <morten@...kler.dk>
To:	linux-kernel@...r.kernel.org
Subject: Possible bug in inotify api

To whom it might concern

I'd like to report a possible malfunction of the inotify api and check if
this issue has been reported.
If this is not the proper place to do so, please let me know. I have
searched the archives and the web and found similar reportings but none
the same.

The observed behavior is when calling inotify_remove_watch. Now and then
it returns error 22, INVALID_ARGUMENT, even though the watchdesriptor
ought to be valid. I've seen that people complain about this behavior on
the dovecot mailing list but nobody seems to have suggested a fix.

I've attached a small program that I use to reproduce the behavior.
The program watches /tmp and whenever it's notified about a directory
created in /tmp, my program adds a watch for that directory as well.

The program is a C++ program (as I will need the inotify functionality in
a C++ program, but the behavior is the same in a pure C implementation)
and to reproduce I do the following:

* g++ main.cpp
* ./a.out

In a shell I go to /tmp and run
* for i in `seq 1 5000`; do mkdir D-$i; done; for i in `seq 1 5000`; do
rmdir D-$i; done

This makes my testprogram output the wd's created and and the wd's my
program tries to remove. I've never seen the program successfully remove
all 5000 watch descriptors and I've seen inotify_rm_watch fail after 0
removes and after approx 2000 removes and anything in between.

I'm running kernel 2.6.23-5 from the Debian repositories.

If what I've written is totally nonsense, if it is expected behavior or if
I've done anything wrong, please let me know. Also, if I can do anything
further to investigate the misbehavior also, please let me know.

Best and thanks in advance,
   Morten

Attached: C++ program used to reproduce the behavior.

View attachment "main.cpp" of type "text/x-c++src" (3952 bytes)