Bug 230887
| Summary: | Connection to strongswan 5.6.3 produce Fatal data abort | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Henri Hennebert <hlh> |
| Component: | arm | Assignee: | freebsd-arm (Nobody) <freebsd-arm> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Only Me | CC: | Andrew, emaste, imp |
| Priority: | --- | Keywords: | crash, regression |
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Bug Depends on: | |||
| Bug Blocks: | 228911 | ||
I upgrade to FreeBSD norquay.restart.bel 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 r338991 PINE64 arm64 and to strongswan-5.7.0 same panic. There is a small chance that r339251 might help this, especially if you disabled IP option processing. It's not certain, though. This was just committed 5 hours ago... It looks like a buffer overflow or similar stack corruption. x29 should be the frame pointer, however it is zero. I think the load is to check the stack guard, however I've only briefly investigated. (In reply to Warner Losh from comment #2) I upgrade to FreeBSD norquay.restart.bel 12.0-ALPHA9 FreeBSD 12.0-ALPHA9 r339280 PINE64 arm64 And Strongswan 5.7.0 accept vpn connection without problem :-) Thank you all Submitter reports the problem has been fixed after updating. |
Running FreeBSD norquay.restart.bel 12.0-ALPHA3 FreeBSD 12.0-ALPHA3 #0 r338288 on pine64+ 2GB. When I establish a VPN from my phone to strongswan 5.6.3 the system encounter Fatal data abort: x0: 0 x1: 1c x2: ffff0000406e6000 x3: c0000006 x4: 3f x5: 801 x6: ffff000058961e10 x7: ffff000058961e0c x8: 0 x9: ffff000000ac6000 x10: 1 x11: deadbeef x12: f7 x13: 369 x14: 0 x15: 1 x16: ffff0000605552c0 x17: ffff0000003a2c9c x18: ffff0000589626f0 x19: fffffd00684b5a00 x20: 0 x21: 0 x22: 0 x23: 0 x24: 0 x25: ffff0000008b5000 x26: fffffd0009e3702c x27: fffffd0042ac2200 x28: ffff0000008b5000 x29: 0 sp: ffff0000589626f0 lr: ffff0000003e660c elr: ffff0000003e5f98 spsr: 60000005 far: ffffffffffffffa8 Fatal data abort: x0: 0 x1: 1c x2: ffff0000406e6000 x3: c0000006 x4: 3f x5: 801 x6: ffff000058961e10 x7: ffff000058961e0c x8: 0 x9: ffff000000ac6000 x10: 1 x11: deadbeef x12: f7 x13: 369 x14: 0 x15: 1 x16: ffff0000605552c0 x17: ffff0000003a2c9c x18: ffff0000589626f0 x19: fffffd00684b5a00 x20: 0 x21: 0 x22: 0 x23: 0 x24: 0 x25: ffff0000008b5000 x26: fffffd0009e3702c x27: fffffd0042ac2200 x28: ffff0000008b5000 x29: 0 sp: ffff0000589626f0 lr: ffff0000003e660c elr: ffff0000003e5f98 spsr: 60000005 far: ffffffffffffffa8 esr: 96000004 [ thread pid 12 tid 100019 ] Stopped at ip_forward+0x7c: ldr x8, [x29, #-88] db> bt Tracing pid 12 tid 100019 td 0xfffffd000019d000 db_trace_self() at db_stack_trace+0xf0 pc = 0xffff0000005e776c lr = 0xffff00000008b9b4 sp = 0xffff000058962000 fp = 0xffff000058962030 db_stack_trace() at db_command+0x220 pc = 0xffff00000008b9b4 lr = 0xffff00000008b638 sp = 0xffff000058962040 fp = 0xffff000058962120 db_command() at db_command_loop+0x60 pc = 0xffff00000008b638 lr = 0xffff00000008b3fc sp = 0xffff000058962130 fp = 0xffff000058962150 db_command_loop() at db_trap+0xf4 pc = 0xffff00000008b3fc lr = 0xffff00000008e5cc sp = 0xffff000058962160 fp = 0xffff000058962380 db_trap() at kdb_trap+0x1c8 pc = 0xffff00000008e5cc lr = 0xffff0000002fb38c sp = 0xffff000058962390 fp = 0xffff000058962440 --More-- kdb_trap() at data_abort+0x1c0 pc = 0xffff0000002fb38c lr = 0xffff0000005fff7c sp = 0xffff000058962450 fp = 0xffff000058962500 data_abort() at do_el1h_sync+0x11c pc = 0xffff0000005fff7c lr = 0xffff0000005ffcb8 sp = 0xffff000058962510 fp = 0xffff000058962540 do_el1h_sync() at handle_el1h_sync+0x74 pc = 0xffff0000005ffcb8 lr = 0xffff0000005e9874 sp = 0xffff000058962550 fp = 0xffff000058962660 handle_el1h_sync() at ip_forward+0x6ec pc = 0xffff0000005e9874 lr = 0xffff0000003e6608 sp = 0xffff000058962670 fp = 0x0000000000000000 db> The same configuration under 12.0-CURRENT r333055 run smoothly.