[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200529020442.GA526@jagdpanzerIV.localdomain>
Date: Fri, 29 May 2020 11:04:42 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Petr Mladek <pmladek@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Dmitry Vyukov <dvyukov@...gle.com>,
Ondrej Mosnacek <omosnace@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH] twist: allow converting pr_devel()/pr_debug() into
printk(KERN_DEBUG)
On (20/05/25 19:43), Tetsuo Handa wrote:
> >> On Sun 2020-05-24 23:50:34, Tetsuo Handa wrote:
> >>> syzbot found a NULL pointer dereference bug inside mptcp_recvmsg() due to
> >>> ssock == NULL, but this bug manifested inside selinux_socket_recvmsg()
> >>> because pr_debug() was no-op [1].
> >>>
> >>> pr_debug("fallback-read subflow=%p",
> >>> mptcp_subflow_ctx(ssock->sk));
> >>> copied = sock_recvmsg(ssock, msg, flags);
> >>
> >> The NULL pointer deference was found even without this patch.
> >> This patch would just cause that it will manifest itself on another
> >> place. What is the benefit, please?
>
> It would help localizing the bug in this specific case.
>
> It's not only about %p, even %d can crash kernel or leak sensitive
> info (if it happens after-free/out-of-bounds/uninit). Overall it
> increases code coverage and allows to catch more bugs earlier.
I don't know. Relying on random pr_debug()-s that can be added or
removed any time. oops backtrace should help with that. You are
not going to add pr_debug() all over the kernel, are you?
-ss
Powered by blists - more mailing lists