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-next>] [day] [month] [year] [list]
Message-ID: <s5htv00m5sb.wl-tiwai@suse.de>
Date:   Thu, 28 May 2020 17:35:16 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Roberto Sassu <roberto.sassu@...wei.com>
Cc:     linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Oops at boot with linux-next kernel with IMA boot options

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ