From: Yang Yingliang <yangyingliang@huawei.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
Oleg Nesterov <oleg@redhat.com>, <john.johansen@canonical.com>,
"chengjian (D)" <cj.chengjian@huawei.com>,
Kees Cook <keescook@chromium.org>, NeilBrown <neilb@suse.com>,
Anna Schumaker <Anna.Schumaker@netapp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"Xiexiuqi (Xie XiuQi)" <xiexiuqi@huawei.com>,
Li Bin <huawei.libin@huawei.com>,
"Jason Yan" <yanaijie@huawei.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Linux Security Module list
<linux-security-module@vger.kernel.org>,
SELinux <selinux@vger.kernel.org>,
Yangyingliang <yangyingliang@huawei.com>,
Cheng Jian <cj.chengjian@huawei.com>
Subject: Re: kernel BUG at kernel/cred.c:434!
Date: Fri, 19 Apr 2019 22:34:29 +0800 [thread overview]
Message-ID: <5CB9DC75.7010600@huawei.com> (raw)
In-Reply-To: <CAHC9VhTdJ6uUOjyxrk=+iOkKe=VN+N9DMPtV=OchAY34x95g=w@mail.gmail.com>
On 2019/4/19 21:24, Paul Moore wrote:
> On Thu, Apr 18, 2019 at 10:42 PM Yang Yingliang
> <yangyingliang@huawei.com> wrote:
>> On 2019/4/19 10:04, Paul Moore wrote:
>>> On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
>>> <yangyingliang@huawei.com> wrote:
>>>> On 2019/4/18 8:24, Casey Schaufler wrote:
>>>>> On 4/17/2019 4:39 PM, Paul Moore wrote:
>>>>>> Since it looks like all three LSMs which implement the setprocattr
>>>>>> hook are vulnerable I'm open to the idea that proc_pid_attr_write() is
>>>>>> a better choice for the cred != read_cred check, but I would want to
>>>>>> make sure John and Casey are okay with that.
>>>>>>
>>>>>> John?
>>>>>>
>>>>>> Casey?
>>>>> I'm fine with the change going into proc_pid_attr_write().
>>>> The cred != real_cred checking is not enough.
>>>>
>>>> Consider this situation, when doing override, cred, real_cred and
>>>> new_cred are all same:
>>>>
>>>> after override_creds() cred == real_cred == new1_cred
>>> I'm sorry, you've lost me. After override_creds() returns
>>> current->cred and current->real_cred are not going to be the same,
>>> yes?
>> It's possible the new cred is equal to current->real_cred and
>> current->cred,
>> so after overrides_creds(), they have the same value.
> Both task_struct.cred and task_struct.real_cred are pointer values,
> assuming that one uses prepare_creds() to allocate/initialize a new
> cred struct for use with override_creds() then the newly created cred
> should never be equal to task_struct.real_cred. Am I missing
> something, or are you thinking of something else?
In do_acct_process(), file->f_cred may equal to current->real_cred, I
confirm
it by adding some debug message in do_acct_process() like this:
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -481,6 +481,7 @@ static void do_acct_process(struct bsd_acct_struct
*acct)
flim = current->signal->rlim[RLIMIT_FSIZE].rlim_cur;
current->signal->rlim[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY;
/* Perform file operations on behalf of whoever enabled
accounting */
+ pr_info("task:%px new cred:%px real cred:%px cred:%px\n",
current, file->f_cred, current->real_cred, current->cred);
orig_cred = override_creds(file->f_cred);
Messages:
[ 56.643298] task:ffff88841a9595c0 new cred:ffff88841ae450c0 real
cred:ffff88841ae450c0 cred:ffff88841ae450c0 //They are same.
[ 56.646609] Process accounting resumed
[ 56.649943] task:ffff88841a9595c0 new cred:ffff88841ae450c0 real
cred:ffff88841c96c300 cred:ffff88841ae450c0
[ 56.653565] ------------[ cut here ]------------
[ 56.655119] kernel BUG at kernel/cred.c:434!
[ 56.656590] invalid opcode: 0000 [#1] SMP PTI
[ 56.658033] CPU: 2 PID: 4169 Comm: syz-executor.15 Not tainted
5.1.0-rc4-00034-g869e3305f23d-dirty #143
[ 56.661077] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 56.664895] RIP: 0010:commit_creds+0x1eb/0x230
[ 56.666344] Code: 43 1c 0f 85 08 ff ff ff e9 10 ff ff ff 8b 45 10 39
43 10 0f 85 18 ff ff ff 8b 43 20 39 45 20 0f 85 0c ff ff ff e9 14 ff ff
ff <0f> 0b 48 c7 c7 d0 d2 49 82 e8 17 3b 3e 00 0f 0b 48 c7 c7 c0 d2 49
[ 56.672410] RSP: 0018:ffffc90003a17b20 EFLAGS: 00010287
[ 56.674098] RAX: ffff88841a9595c0 RBX: ffff88841ae450c0 RCX:
0000000000000000
[ 56.676410] RDX: 0000000000000001 RSI: 0000000000000020 RDI:
ffff88841c96ce40
[ 56.678691] RBP: 0000000000000001 R08: 0000000000800000 R09:
0000000000000000
[ 56.680997] R10: ffff88841c9265a0 R11: ffffffff810d6940 R12:
ffff88841a9595c0
[ 56.681198] task:ffff88841a9195c0 new cred:ffff88841aeaa0c0 real
cred:ffff88841aeaa0c0 cred:ffff88841aeaa0c0
[ 56.683293] R13: 0000000000000040 R14: ffff88841c96ce40 R15:
0000000000000040
[ 56.683296] FS: 00007f5969a5c700(0000) GS:ffff88842fa80000(0000)
knlGS:0000000000000000
[ 56.683297] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 56.683299] CR2: 00007f82742214f0 CR3: 000000041cbc0005 CR4:
00000000000206e0
[ 56.683305] Call Trace:
[ 56.683340] selinux_setprocattr+0x17b/0x480
[ 56.686513] Process accounting resumed
[ 56.688849] proc_pid_attr_write+0xc0/0xf0
[ 56.688857] __kernel_write+0x4f/0xf0
[ 56.688866] do_acct_process+0x538/0x750
[ 56.703090] ? __schedule+0x290/0x960
[ 56.704311] ? __queue_work+0x160/0x5c0
[ 56.705571] acct_pin_kill+0x1e/0x70
[ 56.706743] pin_kill+0x81/0x150
[ 56.707813] ? finish_wait+0x80/0x80
[ 56.708985] mnt_pin_kill+0x1e/0x30
[ 56.710127] cleanup_mnt+0x6e/0x70
[ 56.711247] task_work_run+0x8a/0xb0
[ 56.712453] do_exit+0x2e0/0xc80
[ 56.713525] do_group_exit+0x33/0xb0
[ 56.714701] get_signal+0x143/0x810
[ 56.715865] do_signal+0x36/0x610
[ 56.716962] ? __x64_sys_futex+0x134/0x180
[ 56.718307] ? _copy_to_user+0x22/0x30
[ 56.719606] exit_to_usermode_loop+0x80/0xe0
[ 56.721003] do_syscall_64+0x16c/0x180
[ 56.722242] entry_SYSCALL_64_after_hwframe+0x44/0xa9
next prev parent reply other threads:[~2019-04-19 18:21 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-12 6:21 kernel BUG at kernel/cred.c:434! chengjian (D)
2019-04-12 15:28 ` Casey Schaufler
2019-04-15 13:43 ` Oleg Nesterov
2019-04-15 14:48 ` Paul Moore
2019-04-15 15:05 ` Oleg Nesterov
2019-04-15 16:20 ` Paul Moore
2019-04-16 3:40 ` Kees Cook
2019-04-16 14:46 ` chengjian (D)
2019-04-17 14:30 ` Paul Moore
2019-04-17 14:57 ` Oleg Nesterov
2019-04-17 15:39 ` Casey Schaufler
2019-04-17 15:40 ` Paul Moore
2019-04-17 16:27 ` Oleg Nesterov
2019-04-17 16:42 ` Casey Schaufler
2019-04-18 13:39 ` Stephen Smalley
2019-04-17 23:39 ` Paul Moore
2019-04-18 0:17 ` John Johansen
2019-04-18 0:24 ` Casey Schaufler
2019-04-18 2:49 ` Yang Yingliang
2019-04-19 2:04 ` Paul Moore
2019-04-19 2:34 ` Yang Yingliang
2019-04-19 13:24 ` Paul Moore
2019-04-19 14:34 ` Yang Yingliang [this message]
2019-04-19 16:13 ` Paul Moore
2019-04-20 7:38 ` Yang Yingliang
2019-04-22 19:48 ` Paul Moore
2019-04-23 4:08 ` Yang Yingliang
2019-04-23 20:18 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5CB9DC75.7010600@huawei.com \
--to=yangyingliang@huawei.com \
--cc=Anna.Schumaker@netapp.com \
--cc=casey@schaufler-ca.com \
--cc=cj.chengjian@huawei.com \
--cc=huawei.libin@huawei.com \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=neilb@suse.com \
--cc=oleg@redhat.com \
--cc=paul@paul-moore.com \
--cc=peterz@infradead.org \
--cc=selinux@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=xiexiuqi@huawei.com \
--cc=yanaijie@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.