Core update 170 BUG: KFENCE: use-after-free with RTL 8153 USB adapter

[pscar13 (Phil SCAR)]

Hello,

After ASIX AX8819 USB adapters issue

ASIX ax88179_178a USB-to-LAN adapter unusable after Core Update 170

Hi all, for your information: I just pushed an update to Linux 5.15.68 to the upcoming Core Update 171 (commit), which should include the aforementioned upstream fixes for making ASIX ax88179_178a NICs work again. For x86_64, the updated kernel should be available in the “unstable” repository within the next four hours. ARM builds may take slightly longer. It would be very helpful if you could test Core Update 171 from the “unstable” repository, to confirm that the issue is actually fixed by …

I had the bad idea to buy new RTL 8153 USB adapter and put them on GREEN and BLUE

Since I installed them I get many errors in the logs:

Sep 21 11:30:44 ipfire kernel: ==================================================================
Sep 21 11:30:44 ipfire kernel: BUG: KFENCE: use-after-free read in ipt_do_table+0x17f/0x740
Sep 21 11:30:44 ipfire kernel:
Sep 21 11:30:44 ipfire kernel: Use-after-free read at 0x0000000086fb3d3c (in kfence-#89):
Sep 21 11:30:44 ipfire kernel:  ipt_do_table+0x17f/0x740
Sep 21 11:30:44 ipfire kernel:  nf_hook_slow+0x3f/0xc0
Sep 21 11:30:44 ipfire kernel:  ip_output+0x137/0x180
Sep 21 11:30:44 ipfire kernel:  ip_forward+0x40e/0x540
Sep 21 11:30:44 ipfire kernel:  ip_sublist_rcv_finish+0x6f/0x80
Sep 21 11:30:44 ipfire kernel:  ip_sublist_rcv+0x181/0x210
Sep 21 11:30:44 ipfire kernel:  ip_list_rcv+0xf8/0x130
Sep 21 11:30:44 ipfire kernel:  __netif_receive_skb_list_core+0x232/0x250
Sep 21 11:30:44 ipfire kernel:  netif_receive_skb_list_internal+0x1ab/0x2f0
Sep 21 11:30:44 ipfire kernel:  napi_complete_done+0x6f/0x1c0
Sep 21 11:30:44 ipfire kernel:  r8152_poll+0x6a5/0x830 [r8152]
Sep 21 11:30:44 ipfire kernel:  __napi_poll+0x2a/0x160
Sep 21 11:30:44 ipfire kernel:  net_rx_action+0x2ec/0x580
Sep 21 11:30:44 ipfire kernel:  __do_softirq+0xc6/0x282
Sep 21 11:30:44 ipfire kernel:  irq_exit_rcu+0x8d/0xb0
Sep 21 11:30:44 ipfire kernel:  common_interrupt+0x80/0xa0
Sep 21 11:30:44 ipfire kernel:  asm_common_interrupt+0x21/0x40
Sep 21 11:30:44 ipfire kernel:  cpuidle_enter_state+0xc7/0x380
Sep 21 11:30:44 ipfire kernel:  cpuidle_enter+0x29/0x40
Sep 21 11:30:44 ipfire kernel:  do_idle+0x1c3/0x200
Sep 21 11:30:44 ipfire kernel:  cpu_startup_entry+0x19/0x20
Sep 21 11:30:44 ipfire kernel:  secondary_startup_64_no_verify+0xb0/0xbb
Sep 21 11:30:44 ipfire kernel:
Sep 21 11:30:44 ipfire kernel: kfence-#89: 0x0000000042ad40bf-0x0000000010535cfc, size=640, cache=kmalloc-1k
Sep 21 11:30:44 ipfire kernel:
Sep 21 11:30:44 ipfire kernel: allocated by task 0 on cpu 1 at 2477.416724s:
Sep 21 11:30:44 ipfire kernel:  __alloc_skb+0x84/0x1d0
Sep 21 11:30:44 ipfire kernel:  __napi_alloc_skb+0x3e/0x110
Sep 21 11:30:44 ipfire kernel:  r8152_poll+0x3e9/0x830 [r8152]
Sep 21 11:30:44 ipfire kernel:  __napi_poll+0x2a/0x160
Sep 21 11:30:44 ipfire kernel:  net_rx_action+0x2ec/0x580
Sep 21 11:30:44 ipfire kernel:  __do_softirq+0xc6/0x282
Sep 21 11:30:44 ipfire kernel:  irq_exit_rcu+0x8d/0xb0
Sep 21 11:30:44 ipfire kernel:  common_interrupt+0x80/0xa0
Sep 21 11:30:44 ipfire kernel:  asm_common_interrupt+0x21/0x40
Sep 21 11:30:44 ipfire kernel:  cpuidle_enter_state+0xc7/0x380
Sep 21 11:30:44 ipfire kernel:  cpuidle_enter+0x29/0x40
Sep 21 11:30:44 ipfire kernel:  do_idle+0x1c3/0x200
Sep 21 11:30:44 ipfire kernel:  cpu_startup_entry+0x19/0x20
Sep 21 11:30:44 ipfire kernel:  secondary_startup_64_no_verify+0xb0/0xbb
Sep 21 11:30:44 ipfire kernel:
Sep 21 11:30:44 ipfire kernel: freed by task 0 on cpu 1 at 2477.416877s:
Sep 21 11:30:44 ipfire kernel:  pskb_expand_head+0x10f/0x350
Sep 21 11:30:44 ipfire kernel:  __pskb_pull_tail+0x52/0x400
Sep 21 11:30:44 ipfire kernel:  match+0x146/0x66c [xt_layer7]
Sep 21 11:30:44 ipfire kernel:  ipt_do_table+0x2a3/0x740
Sep 21 11:30:44 ipfire kernel:  nf_hook_slow+0x3f/0xc0
Sep 21 11:30:44 ipfire kernel:  ip_output+0x137/0x180
Sep 21 11:30:44 ipfire kernel:  ip_forward+0x40e/0x540
Sep 21 11:30:44 ipfire kernel:  ip_sublist_rcv_finish+0x6f/0x80
Sep 21 11:30:44 ipfire kernel:  ip_sublist_rcv+0x181/0x210
Sep 21 11:30:44 ipfire kernel:  ip_list_rcv+0xf8/0x130
Sep 21 11:30:44 ipfire kernel:  __netif_receive_skb_list_core+0x232/0x250
Sep 21 11:30:44 ipfire kernel:  netif_receive_skb_list_internal+0x1ab/0x2f0
Sep 21 11:30:44 ipfire kernel:  napi_complete_done+0x6f/0x1c0
Sep 21 11:30:44 ipfire kernel:  r8152_poll+0x6a5/0x830 [r8152]
Sep 21 11:30:44 ipfire kernel:  __napi_poll+0x2a/0x160
Sep 21 11:30:44 ipfire kernel:  net_rx_action+0x2ec/0x580
Sep 21 11:30:44 ipfire kernel:  __do_softirq+0xc6/0x282
Sep 21 11:30:44 ipfire kernel:  irq_exit_rcu+0x8d/0xb0
Sep 21 11:30:44 ipfire kernel:  common_interrupt+0x80/0xa0
Sep 21 11:30:44 ipfire kernel:  asm_common_interrupt+0x21/0x40
Sep 21 11:30:44 ipfire kernel:  cpuidle_enter_state+0xc7/0x380
Sep 21 11:30:44 ipfire kernel:  cpuidle_enter+0x29/0x40
Sep 21 11:30:44 ipfire kernel:  do_idle+0x1c3/0x200
Sep 21 11:30:44 ipfire kernel:  cpu_startup_entry+0x19/0x20
Sep 21 11:30:44 ipfire kernel:  secondary_startup_64_no_verify+0xb0/0xbb
Sep 21 11:30:44 ipfire kernel:
Sep 21 11:30:44 ipfire kernel: CPU: 1 PID: 0 Comm: swapper/1 Tainted: G    B             5.15.59-ipfire #1
Sep 21 11:30:44 ipfire kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./nT-iBT18/nT-iBT19/nT-iBT29, BIOS D72F1P04_x64 05/21/2014
Sep 21 11:30:44 ipfire kernel: ==================================================================

It doesn’t seem to cause any disconnections.

Any idea to work around this problem?

Thanks in advance.

[bonnietwin (Adolf Belka)]

Searching in the forum posts for “kfence use after free” came up with this thread from beginning of this year.
https://community.ipfire.org/t/bug-kfence-use-after-free-read-in-ipt-do-t/6888

where a kernel update gave an increased number of driver issues. For many people that was solved with the upgrade to kernel 5.15.35 in Core Update 167 but some people still reported problems with their NICs so likely that kernel update did not fix all the driver issues.

The plan is to squeeze a kernel update into Core Update 171 to hopefully fix the ASIX USB issue.
Maybe that new kernel will also have further fixes for the KFENCE use after free bug.

[pscar13 (Phil SCAR)]

Thanks,

I have of course tested Linux kernel update 5.15.68 (Core-Update 171 Development Build: next/d33651d7) offered by @pmueller

The problem has not been solved, still the same BUG: KFENCE.

[pmueller (Peter Müller)]

Hi,

thank you for testing and reporting back.

Yes, these kernel errors crop up every now and then for quite some time - looks like the root cause is still not fixed upstream, but apparently, functionality is not affected. Still ugly though…

@pscar13

The problem has not been solved

Did you check whether the ASIX NIC was working properly?

Someone reported here to have upgraded to C171, and did not make a difference, but I am not sure if they already got the updated kernel at the time the Core Update was downloaded.

Thanks, and best regards,
Peter Müller

[pscar13 (Phil SCAR)]

Thank you for your reply,

After your message, I reinstalled my USB ASIX AX99179 on RED and BLUE on the C171 (Kernel 5.15.68) as they were on the 170 when I had the RED disconnection problems.

No disconnection for three hours, it seems to work fine, I’ll leave it like that until then.

My Profile is here

I’m afraid I bought my RTL 8153 for nothing

[pscar13 (Phil SCAR)]

Hello,

After several tests on C169 and C170.

I discovered that “BUG: KFENCE use-after-free read errors” on RTL 8153 occur when I enable QoS.

When I disable QoS no more errors