I'm running Linus' tip as of today, but have seen this in the 5.8.0-18 stock
kernel from Ubuntu.

All of a sudden, after an "apt update", I'd find my laptop (Dell XPS 7390 2-in-1)
randomly rebooted after an OOPS. I've got pstore on, so I found the cause was in
tpm2_bios_measurements_start() (see full dump attached). I guess the "fwupd"
package was what was updated that killed it, as I can reliably stumble upon this
by running "fwupdtpmevlog" (version 1.4.5) even with no arguments.

----
<1>[   76.550116][ T2332] #PF: supervisor read access in kernel mode
<1>[   76.550117][ T2332] #PF: error_code(0x0000) - not-present page
<6>[   76.550119][ T2332] PGD 0 P4D 0
<4>[   76.550121][ T2332] Oops: 0000 [#1] PREEMPT SMP NOPTI
<4>[   76.550123][ T2332] CPU: 0 PID: 2332 Comm: fwupdtpmevlog Tainted: G S   U            5.9.0-rc4-XPS-TB-Kenny+ #8
<4>[   76.550124][ T2332] Hardware name: Dell Inc. XPS 13 7390 2-in-1/06CDVY, BIOS 1.5.0 06/05/2020
<4>[   76.550129][ T2332] RIP: 0010:tpm2_bios_measurements_start+0x35/0x2c0
<4>[   76.550131][ T2332] Code: 54 55 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 70 48 8b 1e 4c
8b 80 d0 06 00 00 4c 8b b8 d8 06 00 00 <45> 8b 48 1c 4c 89 c8 49 83 c1 20 48 85 db 75 2e 4d 01 c1 4d 39 cf
<4>[   76.550132][ T2332] RSP: 0018:ffffb0dc80b5fe20 EFLAGS: 00010282
<4>[   76.550133][ T2332] RAX: ffff9ec7eb3ae000 RBX: 0000000000000000 RCX: 0000321490006680
<4>[   76.550134][ T2332] RDX: 0000000000009628 RSI: ffff9ec7e345e5c8 RDI: ffff9ec7e345e5a0
----

This is my TPM device:
----
$ dmesg | fgrep -i tpm
[    0.000000] efi: SMBIOS=0x62865000 TPMFinalLog=0x63f57000 ACPI=0x63ffe000 ACPI 2.0=0x63ffe014 ESRT=0x62784018 MEMATTR=0x5f71d018 PROP=0x4272e170 RNG=0x627b0618 TPMEventLog=0x61eecf98
[    0.002936] ACPI: SSDT 0x0000000063FB0000 000612 (v02 DELL   Tpm2Tabl 00001000 INTL 20180927)
[    0.002938] ACPI: TPM2 0x0000000063FAF000 000034 (v04 DELL   Dell Inc 20170001 ??LL 20160422)
[    1.230051] Asymmetric key parser 'tpm_parser' registered
[    1.271418] tpm_tis STM7408:00: 2.0 TPM (device-id 0x0, rev-id 78)
$
-----

I've been trying to figure out what the problem was, checking (via printk())
the values for "seq_file" and "pos" for null, or one of the associated pointers
derived from it, and they "printk()" OK, but if I let the code go much further than
the declaration block, it oopses.

I'm now wondering if the "m->private" data being passed is valid. But in any case,
userspace reading a sysfs file (/sys/kernel/security/tpm0/binary_bios_measurements)
shouldn't cause a kernel panic.

Is there anything I can do to help diagnose and fix this?

Thanks,

	-Kenny

-- 
Kenneth R. Crudup  Sr. SW Engineer, Scott County Consulting, Orange County CA