GUO Zihua
a6176a802c
ima: Avoid blocking in RCU read-side critical section
...
commit 9a95c5bfbf02a0a7f5983280fe284a0ff0836c34 upstream.
A panic happens in ima_match_policy:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
PGD 42f873067 P4D 0
Oops: 0000 [#1 ] SMP NOPTI
CPU: 5 PID: 1286325 Comm: kubeletmonit.sh
Kdump: loaded Tainted: P
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 0.0.0 02/06/2015
RIP: 0010:ima_match_policy+0x84/0x450
Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39
7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d
f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea
44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200
RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739
R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970
R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001
FS: 00007f5195b51740(0000)
GS:ff3e278b12d40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
ima_get_action+0x22/0x30
process_measurement+0xb0/0x830
? page_add_file_rmap+0x15/0x170
? alloc_set_pte+0x269/0x4c0
? prep_new_page+0x81/0x140
? simple_xattr_get+0x75/0xa0
? selinux_file_open+0x9d/0xf0
ima_file_check+0x64/0x90
path_openat+0x571/0x1720
do_filp_open+0x9b/0x110
? page_counter_try_charge+0x57/0xc0
? files_cgroup_alloc_fd+0x38/0x60
? __alloc_fd+0xd4/0x250
? do_sys_open+0x1bd/0x250
do_sys_open+0x1bd/0x250
do_syscall_64+0x5d/0x1d0
entry_SYSCALL_64_after_hwframe+0x65/0xca
Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by
ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a
RCU read-side critical section which contains kmalloc with GFP_KERNEL.
This implies a possible sleep and violates limitations of RCU read-side
critical sections on non-PREEMPT systems.
Sleeping within RCU read-side critical section might cause
synchronize_rcu() returning early and break RCU protection, allowing a
UAF to happen.
The root cause of this issue could be described as follows:
| Thread A | Thread B |
| |ima_match_policy |
| | rcu_read_lock |
|ima_lsm_update_rule | |
| synchronize_rcu | |
| | kmalloc(GFP_KERNEL)|
| | sleep |
==> synchronize_rcu returns early
| kfree(entry) | |
| | entry = entry->next|
==> UAF happens and entry now becomes NULL (or could be anything).
| | entry->action |
==> Accessing entry might cause panic.
To fix this issue, we are converting all kmalloc that is called within
RCU read-side critical section to use GFP_ATOMIC.
Fixes: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()")
Cc: stable@vger.kernel.org
Signed-off-by: GUO Zihua <guozihua@huawei.com>
Acked-by: John Johansen <john.johansen@canonical.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-07-18 13:05:44 +02:00
..
2024-06-21 14:52:58 +02:00
2024-06-16 13:32:15 +02:00
2024-06-16 13:32:35 +02:00
2024-01-25 14:37:45 -08:00
2023-01-04 11:39:22 +01:00
2024-07-05 09:12:44 +02:00
2023-11-20 11:06:44 +01:00
2024-07-05 09:12:41 +02:00
2024-06-16 13:32:30 +02:00
2023-07-27 08:43:57 +02:00
2024-06-21 14:52:58 +02:00
2023-12-08 08:46:09 +01:00
2024-04-13 12:58:13 +02:00
2024-04-13 12:58:54 +02:00
2024-07-05 09:12:33 +02:00
2024-06-16 13:32:15 +02:00
2024-07-05 09:12:32 +02:00
2024-07-05 09:12:43 +02:00
2021-05-11 14:47:37 +02:00
2023-01-14 10:16:14 +01:00
2024-02-23 08:41:53 +01:00
2024-06-21 14:53:39 +02:00
2024-06-21 14:53:39 +02:00
2024-06-21 14:53:39 +02:00
2024-02-23 08:42:03 +01:00
2022-04-08 14:40:00 +02:00
2024-07-18 13:05:44 +02:00
2023-09-19 12:20:13 +02:00
2024-05-02 16:23:46 +02:00
2020-10-13 09:17:34 -07:00
2023-04-05 11:23:45 +02:00
2021-09-15 09:50:40 +02:00
2024-05-02 16:23:44 +02:00
2021-06-23 14:42:52 +02:00
2023-12-20 15:44:30 +01:00
2024-07-18 13:05:42 +02:00
2023-03-11 16:40:18 +01:00
2024-06-21 14:52:47 +02:00
2021-04-07 15:00:14 +02:00
2024-07-05 09:12:44 +02:00
2020-10-13 09:17:34 -07:00
2020-11-02 12:14:19 -08:00
2021-07-20 16:05:58 +02:00
2024-06-21 14:52:58 +02:00
2024-06-21 14:52:48 +02:00
2024-07-05 09:12:41 +02:00
2023-07-27 08:43:40 +02:00
2023-06-21 15:45:37 +02:00
2023-04-20 12:10:29 +02:00
2023-04-20 12:10:29 +02:00
2023-05-17 11:47:33 +02:00
2024-05-02 16:23:36 +02:00
2023-04-20 12:10:29 +02:00
2024-06-21 14:53:28 +02:00
2023-01-14 10:15:20 +01:00
2021-03-25 09:04:11 +01:00
2021-03-25 09:04:11 +01:00
2024-06-21 14:53:37 +02:00
2024-07-05 09:12:33 +02:00
2024-04-13 12:59:40 +02:00
2024-06-16 13:32:26 +02:00
2024-07-05 09:12:33 +02:00
2024-06-21 14:53:17 +02:00
2022-08-21 15:16:05 +02:00
2022-06-09 10:20:49 +02:00
2020-10-16 11:11:19 -07:00
2023-11-28 16:54:58 +00:00
2023-05-17 11:47:34 +02:00
2023-03-11 16:40:04 +01:00
2022-04-08 14:40:03 +02:00
2023-09-23 11:01:05 +02:00
2024-03-01 13:16:46 +01:00
2023-01-04 11:39:23 +01:00
2022-04-20 09:23:29 +02:00
2021-07-14 16:55:50 +02:00
2020-09-16 15:18:56 +02:00
2022-02-23 12:01:00 +01:00
2020-09-18 14:24:16 +01:00
2021-09-08 08:49:00 +02:00
2020-10-26 12:12:27 +01:00
2024-07-05 09:12:55 +02:00
2024-06-21 14:52:58 +02:00
2024-06-21 14:53:18 +02:00
2023-01-04 11:39:23 +01:00
2020-10-02 19:11:12 -07:00
2023-08-30 16:23:17 +02:00
2021-09-03 10:09:30 +02:00
2022-01-27 10:54:33 +01:00
2024-06-21 14:53:06 +02:00
2020-10-06 10:31:52 -07:00
2021-05-14 09:50:46 +02:00
2021-09-08 08:49:00 +02:00
2021-03-30 14:32:03 +02:00
2023-03-17 08:45:13 +01:00
2023-07-27 08:43:40 +02:00
2023-11-28 16:54:56 +00:00
2023-12-08 08:46:13 +01:00