Hi Dmitry,
On 12/20/18 4:36 PM, Dmitry Vyukov wrote:
On Wed, Dec 19, 2018 at 10:04 AM Manfred Spraul
<manf...@colorfullife.com> wrote:
Hello Dmitry,
On 12/12/18 11:55 AM, Dmitry Vyukov wrote:
On Tue, Dec 11, 2018 at 9:23 PM syzbot
<syzbot+1145ec2e23165570c...@syzkaller.appspotmail.com> wrote:
Hello,
syzbot found the following crash on:
HEAD commit: f5d582777bcb Merge branch 'for-linus' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=135bc547400000
kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23
dashboard link: https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16803afb400000
+Manfred, this looks similar to the other few crashes related to
semget$private(0x0, 0x4000, 0x3f) that you looked at.
I found one unexpected (incorrect?) locking, see the attached patch.
But I doubt that this is the root cause of the crashes.
But why? These one-off sporadic crashes reported by syzbot looks
exactly like a subtle race and your patch touches sem_exit_ns involved
in all reports.
So if you don't spot anything else, I would say close these 3 reports
with this patch (I see you already included Reported-by tags which is
great!) and then wait for syzbot reaction. Since we got 3 of them, if
it's still not fixed I would expect that syzbot will be able to
retrigger this later again.
As I wrote, unless semop() is used, sma->use_global_lock is always 9 and
nothing can happen.
Every single-operation semop() reduces use_global_lock by one, i.e a
single semop call as done here cannot trigger the bug:
https://syzkaller.appspot.com/text?tag=ReproSyz&x=16803afb400000
But, one more finding:
https://syzkaller.appspot.com/bug?extid=1145ec2e23165570c3ac
https://syzkaller.appspot.com/text?tag=CrashLog&x=109ecf6e400000
The log file contain 1080 lines like these:
semget$private(..., 0x4003, ...)
semget$private(..., 0x4006, ...)
semget$private(..., 0x4007, ...)
It ends up as kmalloc(128*0x400x), i.e. slightly more than 2 MB, an
allocation in the 4 MB kmalloc buffer:
[ 1201.210245] kmalloc-4194304 4698112KB 4698112KB
i.e.: 1147 4 MB kmalloc blocks --> are we leaking nearly 100% of the
semaphore arrays??
This one looks similar:
https://syzkaller.appspot.com/bug?extid=c92d3646e35bc5d1a909
except that the array sizes are mixed, and thus there are kmalloc-1M and
kmalloc-2M as well.
(and I did not count the number of semget calls)
The test apps use unshare(CLONE_NEWNS) and unshare(CLONE_NEWIPC), correct?
I.e. no CLONE_NEWUSER.
https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L1523
--
Manfred