"do_page_fault(): sending SIGSEGV to nft" Should I worry?

Installing and Using OpenWrt
1

Hello ! I have an Edge Router X with OpenWrt 23.05.3.
Just know I saw this on the log:

Wed Feb 26 21:13:21 2025 kern.info kernel: [2518682.699729] do_page_fault(): sending SIGSEGV to nft for invalid read access from 00000000
Wed Feb 26 21:13:21 2025 kern.info kernel: [2518682.716519] epc = 77e3cdc8 in libc.so[77da7000+ab000]
Wed Feb 26 21:13:21 2025 kern.info kernel: [2518682.727064] ra  = 77e3d7cc in libc.so[77da7000+ab000]

I looked at the usage of the router, there is just one device online, doing nothing heavy, memory usage seems low. So I don't understand why this message came out. Is the router perhaps failing? Or what else could be a problem ? I would appreciate your advice !

2

I dont know - what inputs you pass to nft command?
Please upgrade to latest 23.05.5 (auc for the easy way keeping installed packages)
Post outputs of

ubus call system board
cat /etc/config/firewall
cat /etc/config/network
nft list ruleset

edit away any secrets / public IPs / pawwsords/secrets replacng them with ABC
And post here using </> text boxes.

3

The router just restarted, I don't know why. So I guess I should worry! I will update it and post the outputs!

4

nftables executable crashed does not mean router should crash right away.
first suspect would be side processes consuming all memory?

5

No, memory consumption was just normal at the time of do_page_fault(), as far as I checked with luci app statistics. (But with the restart, it's gone!)
Now, nobody seems to be using the internet on that router, I will try to update real quick!!

6

Try 23.05.5 first. It is possible to crash nft with wildly deformed rules, but should not happen with normal rules/maps.

7

Now I'm done with setting up 23.05.5, installed everything I had before. I looked at nft list ruleset and realized that nft has a lot of things from OpenNDS. I'd better ask @bluewavenet in that case. Otherwise I didn't do anything complicated on my own. (so that I didn't even know what nft was.)

do_page_fault() was on 26th, Feb, around 9pm, then the router rebooted on its own on 27th around 3pm. It's not clear if these two incidents are relevant....

8

Kind of I told you it is to choose between auc and luci-app-attendedsysupgrade to maintain packages and configs through update.

Can you recover what opennds was doing around one and other moment. Like 3 new clients last second, immediately roaming etc?

1st event could easily be nft list ruleset | nft -c -o -f - (i.e. completely normal ruleset) , I really need the nft file/pipe that crashed it.

9

@brada4 aah, I didn't know what auc was, I thought you were talking about keeping config. I had thought that one should always reinstall packages because old ones might not be compatible.

What's weird is, as I got do_page_fault(): sending SIGSEGV to nft, there was only one device connected to the router, and that one was not in the interface where opennds is installed. So opennds was not doing anything at all.

At the moment where the router rebooted, there was one authenticated user over opennds. Since the statistics got lost upon reboot, I can't tell if it was triggered by something related to opennds.

I have Omada EAP's with Omada controller, so the router doesn't know anything about roaming.

Here is nft list ruleset


root@OpenWrt-erx2:~# nft list ruleset
table inet fw4 {
	ct helper amanda {
		type "amanda" protocol udp
		l3proto inet
	}

	ct helper RAS {
		type "RAS" protocol udp
		l3proto inet
	}

	ct helper Q.931 {
		type "Q.931" protocol tcp
		l3proto inet
	}

	ct helper irc {
		type "irc" protocol tcp
		l3proto ip
	}

	ct helper pptp {
		type "pptp" protocol tcp
		l3proto ip
	}

	ct helper sip {
		type "sip" protocol udp
		l3proto inet
	}

	ct helper snmp {
		type "snmp" protocol udp
		l3proto ip
	}

	ct helper tftp {
		type "tftp" protocol udp
		l3proto inet
	}

	chain input {
		type filter hook input priority filter; policy accept;
		iifname "lo" accept comment "!fw4: Accept traffic from loopback"
		ct state established,related accept comment "!fw4: Allow inbound established and related flows"
		tcp flags syn / fin,syn,rst,ack jump syn_flood comment "!fw4: Rate limit TCP syn packets"
		meta nfproto ipv6 counter packets 1343 bytes 100886 accept comment "!fw4: IPv6 device drop"
		iifname { "vpn", "wg_s2s_b", "br-lan.12", "br-lan.16" } jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
		iifname "eth0" jump input_wan comment "!fw4: Handle wan IPv4/IPv6 input traffic"
		iifname "br-lan.11" jump input_guests comment "!fw4: Handle guests IPv4/IPv6 input traffic"
		iifname "br-lan.15" jump input_residents comment "!fw4: Handle residents IPv4/IPv6 input traffic"
	}

	chain forward {
		type filter hook forward priority filter; policy drop;
		ct state established,related accept comment "!fw4: Allow forwarded established and related flows"
		meta nfproto ipv6 counter packets 0 bytes 0 drop comment "!fw4: IPv6 any zone drop"
		iifname { "vpn", "wg_s2s_b", "br-lan.12", "br-lan.16" } jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
		iifname "eth0" jump forward_wan comment "!fw4: Handle wan IPv4/IPv6 forward traffic"
		iifname "br-lan.11" jump forward_guests comment "!fw4: Handle guests IPv4/IPv6 forward traffic"
		iifname "br-lan.15" jump forward_residents comment "!fw4: Handle residents IPv4/IPv6 forward traffic"
		jump handle_reject
	}

	chain output {
		type filter hook output priority filter; policy accept;
		oifname "lo" accept comment "!fw4: Accept traffic towards loopback"
		ct state established,related accept comment "!fw4: Allow outbound established and related flows"
		oifname { "vpn", "wg_s2s_b", "br-lan.12", "br-lan.16" } jump output_lan comment "!fw4: Handle lan IPv4/IPv6 output traffic"
		oifname "eth0" jump output_wan comment "!fw4: Handle wan IPv4/IPv6 output traffic"
		oifname "br-lan.11" jump output_guests comment "!fw4: Handle guests IPv4/IPv6 output traffic"
		oifname "br-lan.15" jump output_residents comment "!fw4: Handle residents IPv4/IPv6 output traffic"
	}

	chain prerouting {
		type filter hook prerouting priority filter; policy accept;
		iifname { "vpn", "wg_s2s_b", "br-lan.12", "br-lan.16" } jump helper_lan comment "!fw4: Handle lan IPv4/IPv6 helper assignment"
		iifname "br-lan.11" jump helper_guests comment "!fw4: Handle guests IPv4/IPv6 helper assignment"
		iifname "br-lan.15" jump helper_residents comment "!fw4: Handle residents IPv4/IPv6 helper assignment"
	}

	chain handle_reject {
		meta l4proto tcp reject with tcp reset comment "!fw4: Reject TCP traffic"
		reject comment "!fw4: Reject any other traffic"
	}

	chain syn_flood {
		limit rate 25/second burst 50 packets return comment "!fw4: Accept SYN packets below rate-limit"
		drop comment "!fw4: Drop excess packets"
	}

	chain input_lan {
		jump accept_from_lan
	}

	chain output_lan {
		jump accept_to_lan
	}

	chain forward_lan {
		jump accept_to_wan comment "!fw4: Accept lan to wan forwarding"
		jump accept_to_lan
	}

	chain helper_lan {
		udp dport 10080 ct helper set "amanda" comment "!fw4: Amanda backup and archiving proto"
		udp dport 1719 ct helper set "RAS" comment "!fw4: RAS proto tracking"
		tcp dport 1720 ct helper set "Q.931" comment "!fw4: Q.931 proto tracking"
		meta nfproto ipv4 tcp dport 6667 ct helper set "irc" comment "!fw4: IRC DCC connection tracking"
		meta nfproto ipv4 tcp dport 1723 ct helper set "pptp" comment "!fw4: PPTP VPN connection tracking"
		udp dport 5060 ct helper set "sip" comment "!fw4: SIP VoIP connection tracking"
		meta nfproto ipv4 udp dport 161 ct helper set "snmp" comment "!fw4: SNMP monitoring connection tracking"
		udp dport 69 ct helper set "tftp" comment "!fw4: TFTP connection tracking"
	}

	chain accept_from_lan {
		iifname { "vpn", "wg_s2s_b", "br-lan.12", "br-lan.16" } counter packets 1230 bytes 147407 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
	}

	chain accept_to_lan {
		oifname { "vpn", "wg_s2s_b", "br-lan.12", "br-lan.16" } counter packets 5303 bytes 448456 accept comment "!fw4: accept lan IPv4/IPv6 traffic"
	}

	chain input_wan {
		meta nfproto ipv4 udp dport 68 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCP-Renew"
		icmp type echo-request counter packets 0 bytes 0 accept comment "!fw4: Allow-Ping"
		meta nfproto ipv4 meta l4proto igmp counter packets 211 bytes 7596 accept comment "!fw4: Allow-IGMP"
		meta nfproto ipv6 udp dport 546 counter packets 0 bytes 0 accept comment "!fw4: Allow-DHCPv6"
		ip6 saddr fe80::/10 icmpv6 type . icmpv6 code { mld-listener-query . no-route, mld-listener-report . no-route, mld-listener-done . no-route, mld2-listener-report . no-route } counter packets 0 bytes 0 accept comment "!fw4: Allow-MLD"
		icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply, nd-router-solicit, nd-router-advert } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
		icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, nd-neighbor-solicit . no-route, nd-neighbor-advert . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Input"
		meta nfproto ipv4 udp dport { 51820, 51821, 51822 } counter packets 0 bytes 0 accept comment "!fw4: allow wireguard"
		jump reject_from_wan
	}

	chain output_wan {
		jump accept_to_wan
	}

	chain forward_wan {
		icmpv6 type { destination-unreachable, time-exceeded, echo-request, echo-reply } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
		icmpv6 type . icmpv6 code { packet-too-big . no-route, parameter-problem . no-route, parameter-problem . admin-prohibited } limit rate 1000/second counter packets 0 bytes 0 accept comment "!fw4: Allow-ICMPv6-Forward"
		meta l4proto esp counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-IPSec-ESP"
		udp dport 500 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: Allow-ISAKMP"
		jump reject_to_wan
	}

	chain accept_to_wan {
		meta nfproto ipv4 oifname "eth0" ct state invalid counter packets 123 bytes 5445 drop comment "!fw4: Prevent NAT leakage"
		oifname "eth0" counter packets 7930 bytes 789511 accept comment "!fw4: accept wan IPv4/IPv6 traffic"
	}

	chain reject_from_wan {
		iifname "eth0" counter packets 213 bytes 10549 jump handle_reject comment "!fw4: reject wan IPv4/IPv6 traffic"
	}

	chain reject_to_wan {
		oifname "eth0" counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject wan IPv4/IPv6 traffic"
	}

	chain input_guests {
		counter packets 430 bytes 30693 accept comment "!opennds: users_to_router"
		meta nfproto ipv4 tcp dport { 53, 67, 68 } counter packets 0 bytes 0 accept comment "!fw4: dhcp nds guests"
		meta nfproto ipv4 udp dport { 53, 67, 68 } counter packets 0 bytes 0 accept comment "!fw4: dhcp nds guests"
		jump reject_from_guests
	}

	chain output_guests {
		jump accept_to_guests
	}

	chain forward_guests {
		jump accept_to_wan comment "!fw4: Accept guests to wan forwarding"
		jump reject_to_guests
	}

	chain helper_guests {
		udp dport 10080 ct helper set "amanda" comment "!fw4: Amanda backup and archiving proto"
		udp dport 1719 ct helper set "RAS" comment "!fw4: RAS proto tracking"
		tcp dport 1720 ct helper set "Q.931" comment "!fw4: Q.931 proto tracking"
		meta nfproto ipv4 tcp dport 6667 ct helper set "irc" comment "!fw4: IRC DCC connection tracking"
		meta nfproto ipv4 tcp dport 1723 ct helper set "pptp" comment "!fw4: PPTP VPN connection tracking"
		udp dport 5060 ct helper set "sip" comment "!fw4: SIP VoIP connection tracking"
		meta nfproto ipv4 udp dport 161 ct helper set "snmp" comment "!fw4: SNMP monitoring connection tracking"
		udp dport 69 ct helper set "tftp" comment "!fw4: TFTP connection tracking"
	}

	chain accept_to_guests {
		oifname "br-lan.11" counter packets 6 bytes 1783 accept comment "!fw4: accept guests IPv4/IPv6 traffic"
	}

	chain reject_from_guests {
		iifname "br-lan.11" counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject guests IPv4/IPv6 traffic"
	}

	chain reject_to_guests {
		oifname "br-lan.11" counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject guests IPv4/IPv6 traffic"
	}

	chain input_residents {
		tcp dport { 53, 67, 68 } counter packets 0 bytes 0 accept comment "!fw4: dhcp dns residents"
		udp dport { 53, 67, 68 } counter packets 643 bytes 64163 accept comment "!fw4: dhcp dns residents"
		jump reject_from_residents
	}

	chain output_residents {
		jump accept_to_residents
	}

	chain forward_residents {
		jump accept_to_wan comment "!fw4: Accept residents to wan forwarding"
		jump reject_to_residents
	}

	chain helper_residents {
		udp dport 10080 ct helper set "amanda" comment "!fw4: Amanda backup and archiving proto"
		udp dport 1719 ct helper set "RAS" comment "!fw4: RAS proto tracking"
		tcp dport 1720 ct helper set "Q.931" comment "!fw4: Q.931 proto tracking"
		meta nfproto ipv4 tcp dport 6667 ct helper set "irc" comment "!fw4: IRC DCC connection tracking"
		meta nfproto ipv4 tcp dport 1723 ct helper set "pptp" comment "!fw4: PPTP VPN connection tracking"
		udp dport 5060 ct helper set "sip" comment "!fw4: SIP VoIP connection tracking"
		meta nfproto ipv4 udp dport 161 ct helper set "snmp" comment "!fw4: SNMP monitoring connection tracking"
		udp dport 69 ct helper set "tftp" comment "!fw4: TFTP connection tracking"
	}

	chain accept_to_residents {
		oifname "br-lan.15" counter packets 71 bytes 23288 accept comment "!fw4: accept residents IPv4/IPv6 traffic"
	}

	chain reject_from_residents {
		iifname "br-lan.15" counter packets 25 bytes 1500 jump handle_reject comment "!fw4: reject residents IPv4/IPv6 traffic"
	}

	chain reject_to_residents {
		oifname "br-lan.15" counter packets 0 bytes 0 jump handle_reject comment "!fw4: reject residents IPv4/IPv6 traffic"
	}

	chain dstnat {
		type nat hook prerouting priority dstnat; policy accept;
	}

	chain srcnat {
		type nat hook postrouting priority srcnat; policy accept;
		oifname "eth0" jump srcnat_wan comment "!fw4: Handle wan IPv4/IPv6 srcnat traffic"
	}

	chain srcnat_wan {
		meta nfproto ipv4 masquerade comment "!fw4: Masquerade IPv4 wan traffic"
	}

	chain raw_prerouting {
		type filter hook prerouting priority raw; policy accept;
	}

	chain raw_output {
		type filter hook output priority raw; policy accept;
	}

	chain mangle_prerouting {
		type filter hook prerouting priority mangle; policy accept;
	}

	chain mangle_postrouting {
		type filter hook postrouting priority mangle; policy accept;
	}

	chain mangle_input {
		type filter hook input priority mangle; policy accept;
	}

	chain mangle_output {
		type route hook output priority mangle; policy accept;
	}

	chain mangle_forward {
		type filter hook forward priority mangle; policy accept;
		iifname "eth0" tcp flags syn tcp option maxseg size set rt mtu comment "!fw4: Zone wan IPv4/IPv6 ingress MTU fixing"
		oifname "eth0" tcp flags syn tcp option maxseg size set rt mtu comment "!fw4: Zone wan IPv4/IPv6 egress MTU fixing"
	}
}
table ip nds_filter {
	flowtable ndsftOUT {
		hook ingress priority -100
	}

	chain ndsINP {
		type filter hook input priority -100; policy accept;
		iifname "br-lan.11" counter packets 1043 bytes 89332 jump ndsRTR
	}

	chain ndsFWD {
		type filter hook forward priority -100; policy accept;
		iifname "br-lan.11" counter packets 157987 bytes 10432010 jump ndsNET
	}

	chain nds_ft_OUT {
		meta l4proto { tcp, udp } flow add @ndsftOUT counter packets 859 bytes 116960
		counter packets 157810 bytes 10397804 return
	}

	chain nds_allow_INP {
		type filter hook input priority 100; policy accept;
		iifname "br-lan.11" counter packets 1028 bytes 88111 accept comment "!opennds: allow input"
	}

	chain nds_allow_FWD {
		type filter hook forward priority 100; policy accept;
		iifname "br-lan.11" counter packets 157810 bytes 10397804 accept comment "!opennds: allow forward"
	}

	chain ndsNET {
		ct state invalid counter packets 31 bytes 6441 drop
		ip daddr 192.168.12.1 tcp dport 2050 counter packets 0 bytes 0 accept
		meta mark & 0x00030000 == 0x00020000 counter packets 0 bytes 0 accept
		meta mark & 0x00030000 == 0x00030000 counter packets 157810 bytes 10397804 goto ndsAUT
		counter packets 146 bytes 27765 reject
	}

	chain ndsRTR {
		icmp type echo-request limit rate 4/second counter packets 0 bytes 0 accept
		icmp type echo-request counter packets 0 bytes 0 drop
		ct state invalid counter packets 0 bytes 0 drop
		tcp dport 2050 counter packets 510 bytes 49158 accept
		udp dport 53 counter packets 485 bytes 33201 accept
		udp dport 67 counter packets 10 bytes 3324 accept
		tcp dport 22 counter packets 0 bytes 0 accept
		tcp dport 443 counter packets 0 bytes 0 accept
		tcp dport 53 counter packets 7 bytes 438 accept
		udp dport 68 counter packets 0 bytes 0 accept
		tcp dport 81 counter packets 16 bytes 1990 accept
		counter packets 15 bytes 1221 reject
	}

	chain ndsAUT {
		counter packets 157810 bytes 10397804 jump ndsULR
		counter packets 157810 bytes 10397804 jump nds_ft_OUT
		counter packets 157810 bytes 10397804 accept
		counter packets 0 bytes 0 accept
	}

	chain ndsULR {
		ip saddr 192.168.12.141 counter packets 157751 bytes 10374866 return
		ip saddr 192.168.12.141 counter packets 0 bytes 0 drop
	}
}
table ip nds_mangle {
	flowtable ndsftINC {
		hook ingress priority -100
		devices = { eth0 }
	}

	chain ndsPRE {
		type filter hook prerouting priority dstnat; policy accept;
		iifname "br-lan.11" counter packets 159124 bytes 10541990 jump ndsTRU
		iifname "br-lan.11" counter packets 159124 bytes 10541990 jump ndsOUT
	}

	chain ndsPOST {
		type filter hook forward priority -100; policy accept;
		oifname "br-lan.11" counter packets 96809 bytes 223441721 jump ndsINC
	}

	chain ndsINC {
		ip daddr 192.168.12.141 counter packets 96254 bytes 222947333 meta mark set meta mark | 0x00030000
		oifname "br-lan.11" counter packets 96809 bytes 223441721 jump ndsDLR
		oifname "br-lan.11" counter packets 96809 bytes 223441721 jump nds_ft_INC
		oifname "br-lan.11" counter packets 96809 bytes 223441721 jump nds_ft_INC
	}

	chain nds_ft_INC {
		meta l4proto { tcp, udp } flow add @ndsftINC counter packets 109 bytes 62428
		counter packets 193618 bytes 446883442 return
	}

	chain ndsTRU {
	}

	chain ndsDLR {
		ip daddr 192.168.12.141 counter packets 96254 bytes 222947333 return
		ip daddr 192.168.12.141 counter packets 0 bytes 0 drop
	}

	chain ndsOUT {
		ip saddr 192.168.12.141 ether saddr f6:ed:e1:32:ef:56 counter packets 158251 bytes 10421561 meta mark set meta mark | 0x00030000
	}
}
table ip nds_nat {
	chain ndsPRE {
		type nat hook prerouting priority dstnat; policy accept;
		iifname "br-lan.11" counter packets 1215 bytes 192368 jump ndsOUT
	}

	chain ndsOUT {
		ip daddr 192.168.12.1 tcp dport 80 counter packets 15 bytes 912 redirect to :2050
		meta mark & 0x00030000 == 0x00020000 counter packets 0 bytes 0 return
		meta mark & 0x00030000 == 0x00030000 counter packets 1001 bytes 150652 return
		ip daddr 192.168.12.1 tcp dport 2050 counter packets 7 bytes 436 accept
		tcp dport 80 counter packets 15 bytes 912 dnat to 192.168.12.1:2050
		counter packets 177 bytes 39456 accept
	}
}
root@OpenWrt-erx2:~#

Wow, while I'm writing this post now, I got do_page_fault for nft again!!!!

10

Positive about nft crash is that ruleset is not modified.
tbd by author what are the consequences and what are the causes thereof.

get familiar with auc / luci attendedsysupgrade , if bds author indicates "better" nft is better :wink:

I dont see a fly in them or crashes as you listed them.

11

@brada4 thank you very much for checking ! So nft ruleset is innocent, then.
Sorry, I don't know what you meant by "tbd" and "bds"....

The new crash is


Fri Feb 28 21:37:48 2025 kern.info kernel: [87139.075224] do_page_fault(): sending SIGSEGV to nft for invalid read access from 00000003
Fri Feb 28 21:37:48 2025 kern.info kernel: [87139.091616] epc = 77dc14f0 in libc.so[77d40000+ab000]
Fri Feb 28 21:37:48 2025 kern.info kernel: [87139.101764] ra  = 77ccff05 in libnftables.so.1.1.0[77c8d000+a4000]

More or less the same as Wednesday. Is my router going bad or so, if nft ruleset is OK?

12

This is my output from test-optimizing ruleset on ramips router

[165846.126816] do_page_fault(): sending SIGSEGV to nft for invalid read access from 00000003
[165846.145263] epc = 758a7b54 in libc.so[75821000+b2000]
[165846.180754] ra  = 757943c5 in libnftables.so.1.1.0[7576e000+a4000]

Your initial report was read from 0x0 , so something different.
EDIT: I added the example just as a fun fact, that nft command is not always perfect.

tbd - to be determined (I got no clue on it)
bds - nds typed on mobile phone "keyboard"

13

@brada4 I'm not sure if I understood you right, did you mean by [quote="brada4, post:10, topic:226086"]
tbd by author what are the consequences and what are the causes thereof.
[/quote]

that the whole thing is harmless and I shouldn't worry?

14

The result of whole thing (OpenWrt 23.old) is that nft command did not make intended change. Depending on whether change was to allow or to disallow it is good or bad.

Now you got red herring courtesy trying example crash.
Just sit back and wait if OpenWrt 24.10.0 saves the day (your initial concern is still valid pertaining OpenWrt 23 you dont have anymore)

15

OK! So theoretically, it could cause some trouble, such as denying the internet for the users, if, for example, nft wants to allow something and it didn't work.
But in that case, the user would repeat what they want to do, and if we are lucky, it would work the second time?

In any case, it's not totally harmless, but it's not my fault, nor Opennds nor hardware (because you could reproduce the problem on your router), but openwrt, so the only thing I can do is to wait till openwrt 24.10.x comes out stable (I see some postings that it's not yet stable.) Did I understand it right?

16

24.10.0 is stable , not good on some device groups noted in release notes. Hold the config backup and construct and download current image using auc -n so you can return.

I did not repeat exact bug, just crashed nft knowingly.

Lets see what we can do about it:

Wed Feb 26 21:13:21 2025 kern.info kernel: [2518682.716519] epc = 77e3cdc8 in libc.so[77da7000+ab000]

ubus call system board
opkg search /lib/libc.so

And lets try to determine at least what function is at ab000 in the C library file libc.so

17

Well, I have really no idea about C library..... here is the output:


root@OpenWrt-erx2:~# ubus call system board
{
	"kernel": "5.15.167",
	"hostname": "OpenWrt-erx2",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"model": "Ubiquiti EdgeRouter X",
	"board_name": "ubnt,edgerouter-x",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.5",
		"revision": "r24106-10cc5fcd00",
		"target": "ramips/mt7621",
		"description": "OpenWrt 23.05.5 r24106-10cc5fcd00"
	}
}
root@OpenWrt-erx2:~# opkg search /lib/libc.so
libc - 1.2.4-4

Does it tell you something about ab000 ?

I think I updated ERX to 23.05.03 in the last summer, and this is my first time getting do_page_fault on nft. And twice within a few days, with the router crash. Isn't it strange? Why was it OK for over 1/2 year, and is suddenly doing this?

18

Processes running as root crashing is not fun. No telling yet if it is under outside influence.
If you find a sample that crashed it run nft in gdb to recover backtrace.

19

What do you mean by "outside influence" ?
For now, I let Terminal on my Raspberry pi run ssh to the router, and logread -f. So if the router reboots again, raspi will show what was happening in the last moment.

Could you tell me what gdb is?

20

User provided parameters, like requests and proxied responses with sql escapes or c format strings.

Debugger, that would show call chain leading to crash.