linux-kernel - Re: [BUG] possible deadlock in __schedule (with reproducer available)

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

Message-Id: <20241129173554.11e3b2b2f5126c2b72c6a78e@kernel.org>
Date: Fri, 29 Nov 2024 17:35:54 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Ruan Bonan <bonan.ruan@...us.edu>
Cc: "peterz@...radead.org" <peterz@...radead.org>, "mingo@...hat.com"
 <mingo@...hat.com>, "will@...nel.org" <will@...nel.org>,
 "longman@...hat.com" <longman@...hat.com>, "boqun.feng@...il.com"
 <boqun.feng@...il.com>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "kpsingh@...nel.org" <kpsingh@...nel.org>,
 "mattbobrowski@...gle.com" <mattbobrowski@...gle.com>, "ast@...nel.org"
 <ast@...nel.org>, "daniel@...earbox.net" <daniel@...earbox.net>,
 "andrii@...nel.org" <andrii@...nel.org>, "martin.lau@...ux.dev"
 <martin.lau@...ux.dev>, "eddyz87@...il.com" <eddyz87@...il.com>,
 "song@...nel.org" <song@...nel.org>, "yonghong.song@...ux.dev"
 <yonghong.song@...ux.dev>, "john.fastabend@...il.com"
 <john.fastabend@...il.com>, "sdf@...ichev.me" <sdf@...ichev.me>,
 "haoluo@...gle.com" <haoluo@...gle.com>, "jolsa@...nel.org"
 <jolsa@...nel.org>, "rostedt@...dmis.org" <rostedt@...dmis.org>,
 "mathieu.desnoyers@...icios.com" <mathieu.desnoyers@...icios.com>,
 "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
 "linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Fu Yeqi
 <e1374359@...us.edu>
Subject: Re: [BUG] possible deadlock in __schedule (with reproducer
 available)

On Sat, 23 Nov 2024 03:39:45 +0000
Ruan Bonan <bonan.ruan@...us.edu> wrote:

> 
>        vprintk_emit+0x414/0xb90 kernel/printk/printk.c:2406
>        _printk+0x7a/0xa0 kernel/printk/printk.c:2432
>        fail_dump lib/fault-inject.c:46 [inline]
>        should_fail_ex+0x3be/0x570 lib/fault-inject.c:154
>        strncpy_from_user+0x36/0x230 lib/strncpy_from_user.c:118
>        strncpy_from_user_nofault+0x71/0x140 mm/maccess.c:186
>        bpf_probe_read_user_str_common kernel/trace/bpf_trace.c:215 [inline]
>        ____bpf_probe_read_user_str kernel/trace/bpf_trace.c:224 [inline]

Hmm, this is a combination issue of BPF and fault injection.

static void fail_dump(struct fault_attr *attr)
{
        if (attr->verbose > 0 && __ratelimit(&attr->ratelimit_state)) {
                printk(KERN_NOTICE "FAULT_INJECTION: forcing a failure.\n"
                       "name %pd, interval %lu, probability %lu, "
                       "space %d, times %d\n", attr->dname,
                       attr->interval, attr->probability,
                       atomic_read(&attr->space),
                       atomic_read(&attr->times));

This printk() acquires console lock under rq->lock has been acquired.

This can happen if we use fault injection and trace event too because
the fault injection caused printk warning.
I think this should be a bug of the fault injection, not tracing/BPF.
And to solve this issue, we may be able to check the context and if
it is tracing/NMI etc, fault injection should NOT make it failure.

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>