On Fri, Mar 19, 2021 at 9:22 PM Mimi Zohar [off-list ref] wrote:

On Thu, 2021-03-18 at 07:53 +0100, Dmitry Vyukov wrote:

quoted

On Thu, Mar 18, 2021 at 3:18 AM Mimi Zohar [off-list ref] wrote:

quoted

Hi Dmitry,

On Mon, 2021-03-15 at 14:07 +0100, Dmitry Vyukov wrote:

quoted

On Mon, Mar 15, 2021 at 1:41 PM Mimi Zohar [off-list ref] wrote:

quoted

On Mon, 2021-03-15 at 11:58 +0100, Dmitry Vyukov wrote:

quoted

Hi,

I am trying to boot 5.12-rc3 with this config:
https://github.com/google/syzkaller/blob/cc1cff8f1e1a585894796d6eae8c51eef98037e6/dashboard/config/linux/upstream-smack-kasan.config

in qemu:
qemu-system-x86_64       -enable-kvm     -machine q35,nvdimm -cpu
max,migratable=off -smp 4       -m 4G,slots=4,maxmem=16G        -hda
wheezy.img      -kernel arch/x86/boot/bzImage   -nographic -vga std
 -soundhw all     -usb -usbdevice tablet  -bt hci -bt device:keyboard
   -net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net
nic,model=virtio-net-pci   -object
memory-backend-file,id=pmem1,share=off,mem-path=/dev/zero,size=64M
  -device nvdimm,id=nvdimm1,memdev=pmem1  -append "console=ttyS0
root=/dev/sda earlyprintk=serial rodata=n oops=panic panic_on_warn=1
panic=86400 lsm=smack numa=fake=2 nopcid dummy_hcd.num=8"   -pidfile
vm_pid -m 2G -cpu host

But it crashes on NULL deref in integrity_inode_get during boot:

Run /sbin/init as init process
BUG: kernel NULL pointer dereference, address: 000000000000001c
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc2+ #97
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.13.0-44-g88ab0c15525c-prebuilt.qemu.org 04/01/2014
RIP: 0010:kmem_cache_alloc+0x2b/0x370 mm/slub.c:2920
Code: 57 41 56 41 55 41 54 41 89 f4 55 48 89 fd 53 48 83 ec 10 44 8b
3d d9 1f 90 0b 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 <8b> 5f
1c 4cf
RSP: 0000:ffffc9000032f9d8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff888017fc4f00 RCX: 0000000000000000
RDX: ffff888040220000 RSI: 0000000000000c40 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: ffff888019263627
R10: ffffffff83937cd1 R11: 0000000000000000 R12: 0000000000000c40
R13: ffff888019263538 R14: 0000000000000000 R15: 0000000000ffffff
FS:  0000000000000000(0000) GS:ffff88802d180000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000001c CR3: 000000000b48e000 CR4: 0000000000750ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 integrity_inode_get+0x47/0x260 security/integrity/iint.c:105
 process_measurement+0x33d/0x17e0 security/integrity/ima/ima_main.c:237
 ima_bprm_check+0xde/0x210 security/integrity/ima/ima_main.c:474
 security_bprm_check+0x7d/0xa0 security/security.c:845
 search_binary_handler fs/exec.c:1708 [inline]
 exec_binprm fs/exec.c:1761 [inline]
 bprm_execve fs/exec.c:1830 [inline]
 bprm_execve+0x764/0x19a0 fs/exec.c:1792
 kernel_execve+0x370/0x460 fs/exec.c:1973
 try_to_run_init_process+0x14/0x4e init/main.c:1366
 kernel_init+0x11d/0x1b8 init/main.c:1477
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Modules linked in:
CR2: 000000000000001c
---[ end trace 22d601a500de7d79 ]---

It looks like integrity_inode_get() fails to alloc memory.   Only on
failure to verify the integrity of a file would an error be returned.
I think that is what you would want to happen.  Without an "appraise"
policy, this shouldn't happen.

It happens at the very boot. I think the cache is NULL.

An IMA policy had to have been loaded in order for
integrity_inode_get() to have been called.   If this is happening on
boot, it's too early for a custom policy to have been loaded by
userspace, but I don't see the builtin policy defined on the boot
command line either.

Any additional information would be much appreciated.

Hi Mimi,

I provided kernel config and qemu command line. What other information
are you looking for? Can you reproduce it on your side?

Yes, finally I was able to reproduce the NULL deref.  I just posted two
patches as an RFC.  As described in the 2/2 patch description, it's
unclear why the iint_cache would not be initialized, yet an IMA policy
is loaded.  If the kmem_cache_alloc() for the iint_cache failed, it
would have panic'ed.  Perhaps you have some insights as to how this
might happen.

Once reviewed/tested, I'll re-post a proper patch (fixing the patch
author).

Hi Mimi,

I know almost nothing about the security subsystem in general and
integrity subsystem in particular. I think you are much better
equipped to answer these questions.
You said you can reproduce it, doesn't it allow you to understand what
happens? E.g. by adding maybe some additional printf's to trace
execution of some key initialization points.