libtorrent-rasterbar v2 Linux kernel NULL pointer dereference bug

[JesterEE]

Just an FYI for those that are on a relatively new Linux kernel using deluge (or other libtorrent v2 clients). There seems to be a bad interaction that causes the Linux kernel to throw an error using this library.

I've been dealing with this for a few weeks now running Deluge 2.1.1 (with libtorrent 2.0.8.0) scratching my head until someone kindly pointed me to the libtorrent issue tracker.

See this bug report on the libtorrent issue tracker.
https://github.com/arvidn/libtorrent/issues/6952

This issue is still currently open, but at least the devs are aware. There is nothing to do for the deluge devs except wait for them to figure out what's going on and update to the library when the patch is eventually pushed.

If you are experiencing this issue, you will find your syslog contains something along these lines:

Code: Select all

Oct 11 04:28:23 [kernel] [111115.499140] BUG: kernel NULL pointer dereference, address: 00000000000000d6
Oct 11 04:28:23 [kernel] [111115.499476] #PF: supervisor read access in kernel mode
Oct 11 04:28:23 [kernel] [111115.499744] #PF: error_code(0x0000) - not-present page
Oct 11 04:28:23 [kernel] [111115.499999] PGD 0 P4D 0
Oct 11 04:28:23 [kernel] [111115.500251] Oops: 0000 [#1] PREEMPT SMP NOPTI
Oct 11 04:28:23 [kernel] [111115.500505] CPU: 7 PID: 16002 Comm: Disk Tainted: G           O       6.0.0 #1
Oct 11 04:28:23 [kernel] [111115.500767] Hardware name: To Be Filled By O.E.M. B550 Taichi/B550 Taichi, BIOS P2.20 09/29/2022
Oct 11 04:28:23 [kernel] [111115.501031] RIP: 0010:__filemap_get_folio+0x9c/0x440
Oct 11 04:28:23 [kernel] [111115.501300] Code: 10 e8 a8 a1 5e 00 48 89 c3 48 3d 02 04 00 00 74 e2 48 3d 06 04 00 00 74 da 48 85 c0 0f 84 d2 02 00 00 a8 01 0f 85 d4 02 00 00 <8b> 40 34 85 c0 7
4 c2 8d 50 01 f0 0f b1 53 34 75 f2 48 8b 54 24 28
Oct 11 04:28:23 [kernel] [111115.501595] RSP: 0000:ffff9699c751bc88 EFLAGS: 00010246
Oct 11 04:28:23 [kernel] [111115.501888] RAX: 00000000000000a2 RBX: 00000000000000a2 RCX: 0000000000000002
Oct 11 04:28:23 [kernel] [111115.502186] RDX: 000000000000002c RSI: ffff8b6ff30c9488 RDI: ffff9699c751bc98
Oct 11 04:28:23 [kernel] [111115.502482] RBP: 0000000000000000 R08: 000000000000f96f R09: 000000000000f970
Oct 11 04:28:23 [kernel] [111115.502780] R10: ffffffffffffffc0 R11: 0000000000000000 R12: 0000000000000000
Oct 11 04:28:23 [kernel] [111115.503080] R13: ffff8b76b840a2b0 R14: 000000000000f96f R15: ffff8b6f06fd6be0
Oct 11 04:28:23 [kernel] [111115.503380] FS:  00007fe6853ff6c0(0000) GS:ffff8b7dfe3c0000(0000) knlGS:0000000000000000
Oct 11 04:28:23 [kernel] [111115.503685] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 11 04:28:23 [kernel] [111115.503989] CR2: 00000000000000d6 CR3: 0000000104934000 CR4: 0000000000750ee0
Oct 11 04:28:23 [kernel] [111115.504295] PKRU: 55555554
Oct 11 04:28:23 [kernel] [111115.504600] Call Trace:
Oct 11 04:28:23 [kernel] [111115.504906]  <TASK>
Oct 11 04:28:23 [kernel] [111115.505208]  filemap_fault+0x5a/0x990
Oct 11 04:28:23 [kernel] [111115.505515]  __do_fault+0x36/0x130
Oct 11 04:28:23 [kernel] [111115.505820]  do_fault+0x1da/0x440
Oct 11 04:28:23 [kernel] [111115.506123]  __handle_mm_fault+0x64d/0xe40
Oct 11 04:28:23 [kernel] [111115.506428]  handle_mm_fault+0xae/0x290
Oct 11 04:28:23 [kernel] [111115.506732]  do_user_addr_fault+0x1cd/0x690
Oct 11 04:28:23 [kernel] [111115.507037]  exc_page_fault+0x70/0x170
Oct 11 04:28:23 [kernel] [111115.507343]  asm_exc_page_fault+0x22/0x30
Oct 11 04:28:23 [kernel] [111115.507647] RIP: 0033:0x7fe78358b409
Oct 11 04:28:23 [kernel] [111115.507947] Code: 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 83 fa 20 72 27 <c5> fe 6f 06 48 8
3 fa 40 0f 87 a9 00 00 00 c5 fe 6f 4c 16 e0 c5 fe
Oct 11 04:28:23 [kernel] [111115.508275] RSP: 002b:00007fe6853fd428 EFLAGS: 00010202
Oct 11 04:28:23 [kernel] [111115.508603] RAX: 00007fe7440063a0 RBX: 0000000000000000 RCX: 00007fe6853fd5d0
Oct 11 04:28:23 [kernel] [111115.508931] RDX: 0000000000004000 RSI: 00007fdf0ef6f1a7 RDI: 00007fe7440063a0
Oct 11 04:28:23 [kernel] [111115.509259] RBP: 00007fe6853fd448 R08: 0000000000000003 R09: 0000000000000000
Oct 11 04:28:23 [kernel] [111115.509587] R10: 0000000000000008 R11: 0000000000000246 R12: 0000000000000000
Oct 11 04:28:23 [kernel] [111115.509915] R13: 00007fe774537050 R14: 0000000000000025 R15: 00007fe744001910
Oct 11 04:28:23 [kernel] [111115.510244]  </TASK>

[mhertz]

Found some hinting at issue with transparent_hugepages in kernel being culprit, and disabling it a functioning workaround.

I think you can test that(disabling), through a kernel cmd-line parameter, or tempfiles.d approach.

https://bugzilla.kernel.org/show_bug.cgi?id=216646