[QSDK ipq807x] OpenWrt-19.07 wireguard kernel module crash with 5.4 linux kernel

For Developers
1

Hi Openwrt Folks,

I am getting wiregaurd kernel module crash while wg0 interface bring up itself. I belive my issue is because of the linux kernel versions (4.4 and 5.4 ) compatability problem. If my understanding is wrong please correct me. If its true any patch work or any work around for this issue..?

Below is my packages versioning information and issue logs from my openwrt router.

Openwrt-19.07 (linux v4.4):

Tried below different packages as well.

Wiregurd tools: (User Space - wg )
20210223
20191226
20210424

Wireguard-linux-compact: (Kernel module - wiregaurd.ko)
20210219
20210424
20200611

QSDK ( linux v5.4):

Crash dump :

# /etc/init.d/network restart

# **[ 480.687324] Unable to handle kernel read from unreadable memory at virtual address 00000000000007f0**

**[ 481.029190] CPU: 3 PID: 1351 Comm: kworker/u8:6 Tainted: P 5.4.89 #0**

CPU#/PID#/kernel_version

[ 481.051425] Hardware name: Qualcomm Technologies, Inc. IPQ8074/AP-HK09 (DT)

[ 481.059339] Workqueue: wg-kex-wg10 wg_packet_handshake_send_worker [wireguard]

[ 481.066096] pstate: 80400005 (Nzcv daif +PAN -UAO)

[ 481.073389] pc : iptunnel_xmit+0x150/0x24c

**[ 481.078157] lr : iptunnel_xmit+0x124/0x24c**

[  481.163919] Call trace:
[  481.169213]  iptunnel_xmit+0x150/0x24c
[  481.171386]  udp_tunnel_xmit_skb+0xdc/0xf8 [udp_tunnel]
[  481.175211]  wg_packet_receive+0x92c/0xd78 [wireguard]
[  481.180332]  wg_socket_send_buffer_to_peer+0xcc/0x440 [wireguard]
[  481.185540]  wg_packet_queue_free+0x134/0x3d0 [wireguard]
[  481.191703]  wg_packet_handshake_send_worker+0x18/0x30 [wireguard]
[  481.197089]  process_one_work+0x194/0x270
[  481.203157]  worker_thread+0x200/0x314
[  481.207237]  kthread+0x140/0x150
[  481.210882]  ret_from_fork+0x10/0x18
[  481.214270] Code: 7100a71f 528005e1 7a411304 54000100 (f943f800) 
[  481.217830] ---[ end trace cf2fad6a940c8a89 ]---
[  481.223815] Kernel panic - not syncing: Fatal exception in interrupt
[  481.228510] SMP: stopping secondary CPUs


if (skb_iif)
in_dev = __dev_get_by_index(&init_net, skb_iif);

**netif_is_vxlan(in_dev)) ===> it seems to be unexpected pointer address.

Thanks & Regards,
Rajesh.K

1 Like
2

This is the OpenWrt-forums. You are unlikely to get much help with QSDK here.

2 Likes
3

You should also probably not be sharing your VPN endpoint and private keys to get on it.

4

Agreed here expecting help from openwrt side only. Nothing major role playing QSDK. Issue with latest kernel 5.4 with wiregaurd.

Hope you got my issue .. ?

Thanks in advance for the well supported ideas.

1 Like
5

Thanks for the suggestion. Since I am newbiee here :grinning:

6

To be clear, those keys made it online. I'd burn them completely and make new ones.

2 Likes
7

What device is this and how have you patched in kernel 5.4 into 19.07?

Is there a reason to not upgrade to 22.01?

8

Thanks for your response.

What device is this and how have you patched in kernel 5.4 into 19.07? ==> I am using SDK ( kernel v5.4) which has our some firmware related ( target - ipq807x). 19.07 wiregaurd packages are not able to work with that.

Is there a reason to not upgrade to 22.01? ==> Currently have many firmware depencies on this. Hence not moving to latest 22.01

Is there any approach/patch these(19.07 v4.4) wiregaurd tools and wiregaurd kernel module to make compatiable with ( v5.4 kernel) ..?

Thanks ,
Rajesh.K

9

It's already in the 5.4 kernel.

The SDK questions should be sent to the vendor.

2 Likes
10

If the question is can kernel 4.4 modules be used in kernel 5.4, the answer is no.
Compile the correct modules for 5.4.

And as frollic said, for qsdk issues talk to Qualcomm

1 Like
11

All of the wireguard-linux-compat versions you listed are old. The latest, as of writing, is v1.0.20220627. So maybe try that, and if it doesn't work, send an email to the wireguard mailing list.

12

Thanks very much for the hoping suggestion. Will try the same and get back on this.

1 Like
13

No dude, you should get/go back to Qualcomm.

2 Likes
14

I've taken the liberty to clarify your topic title. The ipq807x target is unsupported on OpenWrt proper, there is development on it, but it is not in even in master yet, much less in 19.07.

Hopefully the Qualcomm people can help you out.

15

Thanks much for the update. Hope will get update as soon as some progress on it. Yeah sure will get help from the Qualcomm people on this particular issue.

16

Hi All,

I have found RCA for the issue. That is NULL check is missing in latest 5.4 kernel which is properly handled in 4.4 kernel function netif_is_vxlan(in_dev)). This could happen when trying to send out packets before interface update in the kernel interfaces look up structure (init_net). After adding NULL checking crash is not seen. Correct me if i am understanding wrong ..?

Below is the difference for the crash function netif_is_vxlan in 5.4 s 4.4 kernel :

4.4 kernel :

static inline bool netif_is_vxlan(const struct net_device *dev)
{
if (!dev)
return false;

    if ((dev->dev.type) &&
            !strncmp(dev->dev.type->name, "vxlan", sizeof("vxlan"))) {
            return true;
    }
    return false;

}

5.4 kernel :

static inline bool netif_is_vxlan(const struct net_device *dev)
{
if (!dev)
return false; ===> added change

    return dev->rtnl_link_ops &&
           !strcmp(dev->rtnl_link_ops->kind, "vxlan");

}

Any suggestions or recommandations would be great to have on this post ..?

Thanks & Regards,
Rajesh.K

1 Like
17

The previous suggestions stand, talk to Qualcomm.

2 Likes
18

Thanks a lot, this patch is working for me and now wireguard is working properly :+1:

19

Thanks. Very helpfull.

This is the patch, maybe will help someone:

vxlan.h: netif_is_vxlan: wg kernel panic patch
===================================================================
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -433,6 +433,7 @@ static inline bool vxlan_addr_multicast(

 static inline bool netif_is_vxlan(const struct net_device *dev)
 {
+       if(!dev) return false;
        return dev->rtnl_link_ops &&
               !strcmp(dev->rtnl_link_ops->kind, "vxlan");
 }
20

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.