Bug 216953 - BUG: kernel NULL pointer dereference, address: 0000000000000008
Summary: BUG: kernel NULL pointer dereference, address: 0000000000000008
Status: NEW
Alias: None
Product: Other
Classification: Unclassified
Component: Loadable Security Modules (LSM) (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Other/LSM
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-01-19 18:25 UTC by Gene
Modified: 2023-01-22 11:23 UTC (History)
2 users (show)

See Also:
Kernel Version: 6.1.7
Tree: Mainline
Regression: Yes


Attachments
kernel config (275.20 KB, text/plain)
2023-01-19 18:25 UTC, Gene
Details
ver_linux output (2.13 KB, text/plain)
2023-01-19 18:26 UTC, Gene
Details
crash log (6.09 KB, text/plain)
2023-01-19 18:26 UTC, Gene
Details
log run rhought decode_stacktrace (9.00 KB, text/plain)
2023-01-19 18:26 UTC, Gene
Details

Description Gene 2023-01-19 18:25:43 UTC
Created attachment 303627 [details]
kernel config

System has RAID6 with ext4 filesystem - 6 x 8TB drives.

Attached are config used to build kernel, output of ver_linux, the raw journal as well as same run through scripts/decode_stacktrace.sh.

Note that while selinux is in kernel, there it is not being used.

thanks.
Comment 1 Gene 2023-01-19 18:26:15 UTC
Created attachment 303628 [details]
ver_linux output
Comment 2 Gene 2023-01-19 18:26:36 UTC
Created attachment 303629 [details]
crash log
Comment 3 Gene 2023-01-19 18:26:57 UTC
Created attachment 303630 [details]
log run rhought decode_stacktrace
Comment 4 Gene 2023-01-19 18:45:33 UTC
system also has 2 x 8TB usb drives using btrfs - but last read/write on that filesystem was 7 or more hours before the crash.
Comment 5 Theodore Tso 2023-01-19 20:21:46 UTC
To save trouble from people who might need to download and read the attachment, here it is:

Jan 19 08:25:35 serv209 kernel: RIP: 0010:selinux_inode_free_security+0x5b/0x90
Jan 19 08:25:35 serv209 kernel: Code: 8b 43 08 4c 8d 63 08 48 03 aa 70 03 00 00 49 39 c4 74 2f 48 83 c5
 40 48 89 ef e8 20 53 7c 00 48 8b 53 08 48 8b 43 10 48 89 ef <48> 89 42 08 48 89 10 4c 89 63 08 4c 89 6
3 10 5b 5d 41 5c e9 6d 54
Jan 19 08:25:35 serv209 kernel: RSP: 0018:ffffb45c404e7ac0 EFLAGS: 00010246
Jan 19 08:25:35 serv209 kernel: RAX: 0000000000000000 RBX: ffff9e7e98002da0 RCX: 0000000000000000
Jan 19 08:25:35 serv209 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9e7c8af2c400
Jan 19 08:25:35 serv209 kernel: RBP: ffff9e7c8af2c400 R08: 0000000000000000 R09: 0000000000000000
Jan 19 08:25:35 serv209 kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff9e7e98002da8
Jan 19 08:25:35 serv209 kernel: R13: ffff9e7c8d7ea800 R14: 0000000000201c2b R15: 000000008070ac00
Jan 19 08:25:35 serv209 kernel: FS:  0000000000000000(0000) GS:ffff9e83cf080000(0000) knlGS:00000000000
00000
Jan 19 08:25:35 serv209 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan 19 08:25:35 serv209 kernel: CR2: 0000000000000008 CR3: 000000083b610006 CR4: 00000000003706e0
Jan 19 08:25:35 serv209 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jan 19 08:25:35 serv209 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jan 19 08:25:35 serv209 kernel: Call Trace:
Jan 19 08:25:35 serv209 kernel:  <TASK>
Jan 19 08:25:35 serv209 kernel:  security_inode_free+0x31/0x70
Jan 19 08:25:35 serv209 kernel:  __destroy_inode+0x71/0x180
Jan 19 08:25:35 serv209 kernel:  destroy_inode+0x2d/0x80
Jan 19 08:25:35 serv209 kernel:  prune_icache_sb+0x7c/0xc0
Jan 19 08:25:35 serv209 kernel:  super_cache_scan+0x15e/0x1f0
Jan 19 08:25:35 serv209 kernel:  do_shrink_slab+0x13e/0x2f0
Jan 19 08:25:35 serv209 kernel:  shrink_slab+0x1f8/0x2a0
Jan 19 08:25:35 serv209 kernel:  shrink_node+0x21c/0x720
Jan 19 08:25:35 serv209 kernel:  balance_pgdat+0x313/0xa70
Jan 19 08:25:35 serv209 kernel:  ? __schedule+0x37f/0x1290
Jan 19 08:25:35 serv209 kernel:  ? get_nohz_timer_target+0x1c/0x1a0
Jan 19 08:25:35 serv209 kernel:  kswapd+0x1fb/0x3c0
Jan 19 08:25:35 serv209 kernel:  ? destroy_sched_domains_rcu+0x30/0x30
Jan 19 08:25:35 serv209 kernel:  ? balance_pgdat+0xa70/0xa70
Jan 19 08:25:35 serv209 kernel:  kthread+0xed/0x120
Jan 19 08:25:35 serv209 kernel:  ? kthread_complete_and_exit+0x20/0x20
Jan 19 08:25:35 serv209 kernel:  ret_from_fork+0x1f/0x30
Jan 19 08:25:35 serv209 kernel:  </TASK>

If selinux is not being used, it's... strange that we could have ended up in this path, since it requires inode->i_security being set and the LSM code deciding that selinux was enabled (and so it called selinux_inode_free_security).

In any case, this is very clearly not an ext4 bug, so I'm going to pass this off to the linux-security-module list for them to investigate.  Without a reliable reproducer, though, there may not be much that any of us can do...
Comment 6 Gene 2023-01-19 20:36:02 UTC
Thanks Ted - sorry to not have a reproducer - this is the only machine that had a problem and just the once (so far!)

I have a second machine running same kernel also with mdadm RAID 6 setup with ext4 - but no problems on that one as of now.

The other item of note, perhaps, is the compiler used was gcc 12.2.1 - earlier kernels used 12.2.0. Build started on fresh base (git -fddx).

Thanks again and sorry for pointing this down the wrong road.

Note You need to log in before you can comment on or make changes to this bug.