Oops at boot with linux-next kernel with IMA boot options

From: Takashi Iwai
Date: Thu May 28 2020 - 11:35:22 EST


Hi Roberto,

it seems that the recent changes in IMA in linux-next caused a
regression: namely it triggers an Oops when booting with the options
ima_policy=tcb ima_template_fmt='d-ng|n-ng|d|ng'

It hits a NULL dereference at ima_match_policy() like:

[ 10.766220] ==================================================================
[ 10.767415] BUG: KASAN: null-ptr-deref in ima_match_policy+0xf7/0xb80
[ 10.768503] Read of size 8 at addr 0000000000000000 by task systemd/1
[ 10.769574]
[ 10.770046] ==================================================================
[ 10.771813] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 10.773049] #PF: supervisor read access in kernel mode
[ 10.773977] #PF: error_code(0x0000) - not-present page
[ 10.774842] PGD 0 P4D 0
[ 10.775302] Oops: 0000 [#1] SMP KASAN PTI
[ 10.776231] CPU: 0 PID: 1 Comm: systemd Tainted: G B 5.7.0-rc7-next-20200526-1.g3f79a08-vanilla #1
[ 10.777882] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
[ 10.779790] RIP: 0010:ima_match_policy+0xf7/0xb80
[ 10.780620] Code: ae 96 ff e8 ab 28 00 00 4c 89 f7 48 89 c3 e8 b0 e9 bf ff 49 89 1e e8 38 ae 96 ff 48 8b 2d 21 2c 8a 02 48 89 ef e8 f9 e8 bf ff <48> 8b 5d 00 c7 44 24 04 00 00 00 00 48 39 dd 0f 84 74 05 00 00 8b
[ 10.783569] RSP: 0018:ffffc9000001fc80 EFLAGS: 00010286
[ 10.784476] RAX: 0000000000000001 RBX: 0000000000000104 RCX: ffffffff91368791
[ 10.786274] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[ 10.787679] RBP: 0000000000000000 R08: ffff88800fdfbd80 R09: fffffbfff27dda0d
[ 10.789089] R10: ffffffff93eed067 R11: fffffbfff27dda0c R12: 0000000000000001
[ 10.790484] R13: ffff88800fdfbd80 R14: 0000000000000000 R15: 000000000000030c
[ 10.792015] FS: 00007f9368b9f940(0000) GS:ffff88806c600000(0000) knlGS:0000000000000000
[ 10.793647] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 10.794613] CR2: 0000000000000000 CR3: 00000000626b8000 CR4: 00000000000006f0
[ 10.796064] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 10.797347] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 10.798576] Call Trace:
[ 10.798993] ? ima_lsm_policy_change+0x2b0/0x2b0
[ 10.799753] ? inode_init_owner+0x1a0/0x1a0
[ 10.800484] ? _raw_spin_lock+0x7a/0xd0
[ 10.801592] ima_must_appraise.part.0+0xb6/0xf0
[ 10.802313] ? ima_fix_xattr.isra.0+0xd0/0xd0
[ 10.803167] ima_must_appraise+0x4f/0x70
[ 10.804004] ima_post_path_mknod+0x2e/0x80
[ 10.804800] do_mknodat+0x396/0x3c0
[ 10.805563] ? do_file_open_root+0x290/0x290
[ 10.806535] do_syscall_64+0x44/0xb0
[ 10.807301] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 10.808360] RIP: 0033:0x7f936713ba90
[ 10.808996] Code: b8 ff ff ff ff c3 0f 1f 40 00 85 ff 49 89 f0 75 41 48 8b 01 89 c1 48 39 c8 75 37 89 d6 4c 89 c7 48 89 c2 b8 85 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 08 f3 c3 66 0f 1f 44 00 00 48 8b 15 d1 73 2c


It's a KVM instance without any TPM stuff, just passed the options
above. I could trigger the same bug on a bare metal, too.

Then I performed bisection and it spotted the commit:
6f1a1d103b48b1533a9c804e7a069e2c8e937ce7
ima: Switch to ima_hash_algo for boot aggregate

Actually reverting this commit fixed the Oops again.

I haven't looked at the change deeply yet, so just reporting.
Please let me know if you come up with a fix.


Thanks!

Takashi