Kismet crashes on aarch64 (Pi 5) with some `monitor.ws` field selections

[motoko2501]

Summary

On Kismet 2025-09-R1 running on a Raspberry Pi 5 (Debian 13 trixie, arm64),
/devices/views/all/monitor.ws crashes the Kismet process with SIGBUS for many
fields selection combinations. The crash is reproducible but
non-deterministic in timing (observed time-to-crash 4 s — ~3.5 min).

Every captured stack trace from this test session ended in:

#0 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()
…
#4 kis_net_web_websocket_endpoint::handle_write()
Bus error (Invalid address alignment [0x6a0f3…])

Frame 0 being shared_ptr control-block release looks consistent with a
use-after-free, alignment, or memory-corruption bug related to the websocket
write path. The Feb 2025 websocket buffer-pool rewrite that switched buffer
types to std::shared_ptr<boost::asio::streambuf>
(1b1426ddf75e500f36efeba86c3a6e113b698d9e) may be relevant, but that is only
a hypothesis.

The faulting addresses observed during this session were clustered in a
0x6a0f1xxx–0x6a0f3cxxx band and increased over successive crashes. I don't
know whether that is meaningful, but it did not look like a simple null pointer
or a normal heap address.

Environment

• Kismet package version: 2025-09-R1
• kismet --version: Kismet 2025.09.0-b5d5a2d04
• Install source: official apt repo
  https://www.kismetwireless.net/repos/apt/release/trixie trixie/main arm64
• Architecture: aarch64 / arm64
• Hardware: Raspberry Pi 5 Model B Rev 1.0
• CPU: 4× Cortex-A76 (CPU part 0xd0b, ARMv8.2-A, variant 0x4, rev 1)
• Kernel: 6.18.29+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.29-1+rpt1 aarch64
• OS: Debian GNU/Linux 13 (trixie), 13.5
• Compiler runtime: libstdc++6 14.2.0-19 (GCC 14)
• libwebsockets19t64: 4.3.5-1+deb13u1
• Boost: libboost-{filesystem,log,program-options,thread}1.83.0-4.2
• OpenSSL: libssl3t64 3.5.6-1~deb13u1
• libfmt10: 10.1.1+ds1-4

Datasource: ar9271-2g (linuxwifi, channel-hopping)

Repro

Authenticate with KISMET=<token> as a query parameter, then subscribe with a
fields selection. Crashes the Kismet process within seconds to minutes.

WebSocket URL:

ws://127.0.0.1:2501/devices/views/all/monitor.ws?KISMET=<token>

Subscription that reproduced the crash repeatedly:

{
  "monitor": "*",
  "request": 9202,
  "rate": 1,
  "fields": [
    "kismet.device.base.key",
    "kismet.device.base.last_time",
    "kismet.device.base.signal/kismet.common.signal.last_signal"
  ]
}

websocat one-liner (no Python needed):

echo '{"monitor":"*","request":9202,"rate":1,"fields":["kismet.device.base.key","kismet.device.base.last_time","kismet.device.base.signal/kismet.common.signal.last_signal"]}' \
  | websocat --no-close "ws://127.0.0.1:2501/devices/views/all/monitor.ws?KISMET=$KISMET_TOKEN"

Result on this build:

• Websocket closes with code 1006 after some number of streamed messages
• systemd reports
  kismet.service: Main process exited, code=killed, status=7/BUS
• Backtrace (representative; identical structure across runs):

Stack trace (most recent call last) in thread XXXXXX:
#16  Object "/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1, at 0xffffffffffffffff, in
#15  Object "/usr/lib/aarch64-linux-gnu/libc.so.6, in
#14  Object "/usr/lib/aarch64-linux-gnu/libc.so.6, in
#13  Object "/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.33, in
#12  Object "/usr/bin/kismet, in
#11  Object "/usr/bin/kismet, in boost::asio::detail::scheduler::do_run_one(...)
#10  Object "/usr/bin/kismet, in boost::asio::detail::strand_service::do_complete(...)
#9..#5  /usr/bin/kismet  (unresolved symbols)
#4   /usr/bin/kismet     in kis_net_web_websocket_endpoint::handle_write()
#3..#1  /usr/bin/kismet  (unresolved symbols)
#0   /usr/bin/kismet     in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()
Bus error (Invalid address alignment [0x6a0f1fa5])

Behavior Matrix

All cases on /devices/views/all/monitor.ws unless noted.

Stable (no crash observed in probe window):

• /eventbus/events.ws with SUBSCRIBE: PACKETCHAIN_STATS (control)

• Subscription with no fields key (full unsimplified records)

• Single-field subscription: kismet.device.base.key

• Single-field subscription: kismet.device.base.last_time

• Single-field subscription: kismet.device.base.signal/kismet.common.signal.last_signal

• Two flat fields: kismet.device.base.key + kismet.device.base.last_time

• Field simplification with [path, alias] rename form survived one 60 s probe:

  [
    "kismet.device.base.key",
    "kismet.device.base.last_time",
    ["kismet.device.base.signal/kismet.common.signal.last_signal", "signal_dbm"]
  ]

Crashes (one or more times, within 4–55 s):

• key + signal (slash-projected)
• last_time + signal (slash-projected)
• signal + key (reversed order, same slash projection)
• key + last_time + signal (slash-projected, three fields, docs-example shape)
• key + last_time + leaf-only signal (kismet.common.signal.last_signal as
  bare leaf)
• Leaf-only kismet.common.signal.last_signal alone
• Unrelated slash projection combined with flat fields:
  key + last_time + kismet.device.base.location/kismet.common.location.avg_loc/kismet.common.location.geopoint

Time-to-crash across the runs that crashed:

4.4 s, 6.3 s, 13.7 s, 17.0 s, 25.8 s, 31.0 s, 32.0 s, 33.5 s, 54.9 s, ~3.5 min

[kismetwireless]

"Fun". Thanks, i'll look into it.

…

-m

On Thursday, May 21st, 2026 at 2:04 PM, motoko2501 ***@***.***> wrote: motoko2501 created an issue [(kismetwireless/kismet#606)](#606) Summary On Kismet 2025-09-R1 running on a Raspberry Pi 5 (Debian 13 trixie, arm64), /devices/views/all/monitor.ws crashes the Kismet process with SIGBUS for many fields selection combinations. The crash is reproducible but non-deterministic in timing (observed time-to-crash 4 s — ~3.5 min). Every captured stack trace from this test session ended in: #0 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() … #4 kis_net_web_websocket_endpoint::handle_write() Bus error (Invalid address alignment [0x6a0f3…]) Frame 0 being shared_ptr control-block release looks consistent with a use-after-free, alignment, or memory-corruption bug related to the websocket write path. The Feb 2025 websocket buffer-pool rewrite that switched buffer types to std::shared_ptr<boost::asio::streambuf> (1b1426d) may be relevant, but that is only a hypothesis. The faulting addresses observed during this session were clustered in a 0x6a0f1xxx–0x6a0f3cxxx band and increased over successive crashes. I don't know whether that is meaningful, but it did not look like a simple null pointer or a normal heap address. Environment - Kismet package version: 2025-09-R1 - kismet --version: Kismet 2025.09.0-b5d5a2d04 - Install source: official apt repo https://www.kismetwireless.net/repos/apt/release/trixie trixie/main arm64 - Architecture: aarch64 / arm64 - Hardware: Raspberry Pi 5 Model B Rev 1.0 - CPU: 4× Cortex-A76 (CPU part 0xd0b, ARMv8.2-A, variant 0x4, rev 1) - Kernel: 6.18.29+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.29-1+rpt1 aarch64 - OS: Debian GNU/Linux 13 (trixie), 13.5 - Compiler runtime: libstdc++6 14.2.0-19 (GCC 14) - libwebsockets19t64: 4.3.5-1+deb13u1 - Boost: libboost-{filesystem,log,program-options,thread}1.83.0-4.2 - OpenSSL: libssl3t64 3.5.6-1~deb13u1 - libfmt10: 10.1.1+ds1-4 Datasource: ar9271-2g (linuxwifi, channel-hopping) Repro Authenticate with KISMET=<token> as a query parameter, then subscribe with a fields selection. Crashes the Kismet process within seconds to minutes. WebSocket URL: ws://127.0.0.1:2501/devices/views/all/monitor.ws?KISMET=<token> Subscription that reproduced the crash repeatedly: { "monitor" : " * " , "request" : 9202 , "rate" : 1 , "fields" : [ " kismet.device.base.key " , " kismet.device.base.last_time " , " kismet.device.base.signal/kismet.common.signal.last_signal " ] } websocat one-liner (no Python needed): echo ' {"monitor":"*","request":9202,"rate":1,"fields":["kismet.device.base.key","kismet.device.base.last_time","kismet.device.base.signal/kismet.common.signal.last_signal"]} ' \ | websocat --no-close " ws://127.0.0.1:2501/devices/views/all/monitor.ws?KISMET= $KISMET_TOKEN " Result on this build: - Websocket closes with code 1006 after some number of streamed messages - systemd reports kismet.service: Main process exited, code=killed, status=7/BUS - Backtrace (representative; identical structure across runs): Stack trace (most recent call last) in thread XXXXXX: #16 Object "/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1, at 0xffffffffffffffff, in #15 Object "/usr/lib/aarch64-linux-gnu/libc.so.6, in #14 Object "/usr/lib/aarch64-linux-gnu/libc.so.6, in #13 Object "/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.33, in #12 Object "/usr/bin/kismet, in #11 Object "/usr/bin/kismet, in boost::asio::detail::scheduler::do_run_one(...) #10 Object "/usr/bin/kismet, in boost::asio::detail::strand_service::do_complete(...) #9..#5 /usr/bin/kismet (unresolved symbols) #4 /usr/bin/kismet in kis_net_web_websocket_endpoint::handle_write() #3..#1 /usr/bin/kismet (unresolved symbols) #0 /usr/bin/kismet in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() Bus error (Invalid address alignment [0x6a0f1fa5]) Behavior Matrix All cases on /devices/views/all/monitor.ws unless noted. Probe duration 30–60 s per case. Most crash detection used Kismet MainPID change after the case; the earliest broad matrix also used journal-window matching, so the legacy endpoint row from that first matrix is treated as inconclusive. Stable (no crash observed in probe window): - /eventbus/events.ws with SUBSCRIBE: PACKETCHAIN_STATS (control) - Subscription with no fields key (full unsimplified records) - Single-field subscription: kismet.device.base.key - Single-field subscription: kismet.device.base.last_time - Single-field subscription: kismet.device.base.signal/kismet.common.signal.last_signal - Two flat fields: kismet.device.base.key + kismet.device.base.last_time - Field simplification with [path, alias] rename form survived one 60 s probe: [ " kismet.device.base.key " , " kismet.device.base.last_time " , [ " kismet.device.base.signal/kismet.common.signal.last_signal " , " signal_dbm " ] ] Crashes (one or more times, within 4–55 s): - key + signal (slash-projected) - last_time + signal (slash-projected) - signal + key (reversed order, same slash projection) - key + last_time + signal (slash-projected, three fields, docs-example shape) - key + last_time + leaf-only signal (kismet.common.signal.last_signal as bare leaf) - Leaf-only kismet.common.signal.last_signal alone - Unrelated slash projection combined with flat fields: key + last_time + kismet.device.base.location/kismet.common.location.avg_loc/kismet.common.location.geopoint Time-to-crash across the runs that crashed: 4.4 s, 6.3 s, 13.7 s, 17.0 s, 25.8 s, 31.0 s, 32.0 s, 33.5 s, 54.9 s, ~3.5 min — Reply to this email directly, [view it on GitHub](#606), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFKJYYYA7IGDBQNYYZW35AT435AJDAVCNFSM6AAAAACZIB6JIOVHI2DSMVQWIX3LMV43ASLTON2WKOZUGQ4TMOBVGEYDIMI). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905) or [Android](https://play.google.com/store/apps/details?id=com.github.android). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dragorn]

This may be fixed in recent nightlies if you want to give them a try.

…

On Thursday, May 21st, 2026 at 2:20 PM, Kismet Wireless ***@***.***> wrote: kismetwireless left a comment [(kismetwireless/kismet#606)](#606 (comment)) "Fun". Thanks, i'll look into it. -m On Thursday, May 21st, 2026 at 2:04 PM, motoko2501 ***@***.***> wrote: > motoko2501 created an issue [(kismetwireless/kismet#606)](#606) > > Summary > > On Kismet 2025-09-R1 running on a Raspberry Pi 5 (Debian 13 trixie, arm64), > /devices/views/all/monitor.ws crashes the Kismet process with SIGBUS for many > fields selection combinations. The crash is reproducible but > non-deterministic in timing (observed time-to-crash 4 s — ~3.5 min). > > Every captured stack trace from this test session ended in: > > #0 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() > … > #4 kis_net_web_websocket_endpoint::handle_write() > Bus error (Invalid address alignment [0x6a0f3…]) > > Frame 0 being shared_ptr control-block release looks consistent with a > use-after-free, alignment, or memory-corruption bug related to the websocket > write path. The Feb 2025 websocket buffer-pool rewrite that switched buffer > types to std::shared_ptr<boost::asio::streambuf> > (1b1426d) may be relevant, but that is only > a hypothesis. > > The faulting addresses observed during this session were clustered in a > 0x6a0f1xxx–0x6a0f3cxxx band and increased over successive crashes. I don't > know whether that is meaningful, but it did not look like a simple null pointer > or a normal heap address. > > Environment > > - Kismet package version: 2025-09-R1 > - kismet --version: Kismet 2025.09.0-b5d5a2d04 > - Install source: official apt repo > https://www.kismetwireless.net/repos/apt/release/trixie trixie/main arm64 > - Architecture: aarch64 / arm64 > - Hardware: Raspberry Pi 5 Model B Rev 1.0 > - CPU: 4× Cortex-A76 (CPU part 0xd0b, ARMv8.2-A, variant 0x4, rev 1) > - Kernel: 6.18.29+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.29-1+rpt1 aarch64 > - OS: Debian GNU/Linux 13 (trixie), 13.5 > - Compiler runtime: libstdc++6 14.2.0-19 (GCC 14) > - libwebsockets19t64: 4.3.5-1+deb13u1 > - Boost: libboost-{filesystem,log,program-options,thread}1.83.0-4.2 > - OpenSSL: libssl3t64 3.5.6-1~deb13u1 > - libfmt10: 10.1.1+ds1-4 > > Datasource: ar9271-2g (linuxwifi, channel-hopping) > > Repro > > Authenticate with KISMET=<token> as a query parameter, then subscribe with a > fields selection. Crashes the Kismet process within seconds to minutes. > > WebSocket URL: > > ws://127.0.0.1:2501/devices/views/all/monitor.ws?KISMET=<token> > > Subscription that reproduced the crash repeatedly: > > { > > "monitor" > > : > > " > > * > > " > > , > > "request" > > : > > 9202 > > , > > "rate" > > : > > 1 > > , > > "fields" > > : [ > > " > > kismet.device.base.key > > " > > , > > " > > kismet.device.base.last_time > > " > > , > > " > > kismet.device.base.signal/kismet.common.signal.last_signal > > " > > ] > } > > websocat one-liner (no Python needed): > > echo > > ' > > {"monitor":"*","request":9202,"rate":1,"fields":["kismet.device.base.key","kismet.device.base.last_time","kismet.device.base.signal/kismet.common.signal.last_signal"]} > > ' > > \ > > | > > websocat --no-close > > " > > ws://127.0.0.1:2501/devices/views/all/monitor.ws?KISMET= > > $KISMET_TOKEN > > " > > Result on this build: > > - Websocket closes with code 1006 after some number of streamed messages > - systemd reports > kismet.service: Main process exited, code=killed, status=7/BUS > - Backtrace (representative; identical structure across runs): > > Stack trace (most recent call last) in thread XXXXXX: > #16 Object "/usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1, at 0xffffffffffffffff, in > #15 Object "/usr/lib/aarch64-linux-gnu/libc.so.6, in > #14 Object "/usr/lib/aarch64-linux-gnu/libc.so.6, in > #13 Object "/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.33, in > #12 Object "/usr/bin/kismet, in > #11 Object "/usr/bin/kismet, in boost::asio::detail::scheduler::do_run_one(...) > #10 Object "/usr/bin/kismet, in boost::asio::detail::strand_service::do_complete(...) > #9..#5 /usr/bin/kismet (unresolved symbols) > #4 /usr/bin/kismet in kis_net_web_websocket_endpoint::handle_write() > #3..#1 /usr/bin/kismet (unresolved symbols) > #0 /usr/bin/kismet in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() > Bus error (Invalid address alignment [0x6a0f1fa5]) > > Behavior Matrix > > All cases on /devices/views/all/monitor.ws unless noted. Probe duration > 30–60 s per case. Most crash detection used Kismet MainPID change after the > case; the earliest broad matrix also used journal-window matching, so the > legacy endpoint row from that first matrix is treated as inconclusive. > > Stable (no crash observed in probe window): > > - > > /eventbus/events.ws with SUBSCRIBE: PACKETCHAIN_STATS (control) > > - > > Subscription with no fields key (full unsimplified records) > > - > > Single-field subscription: kismet.device.base.key > > - > > Single-field subscription: kismet.device.base.last_time > > - > > Single-field subscription: kismet.device.base.signal/kismet.common.signal.last_signal > > - > > Two flat fields: kismet.device.base.key + kismet.device.base.last_time > > - > > Field simplification with [path, alias] rename form survived one 60 s probe: > > [ > > " > > kismet.device.base.key > > " > > , > > " > > kismet.device.base.last_time > > " > > , > [ > > " > > kismet.device.base.signal/kismet.common.signal.last_signal > > " > > , > > " > > signal_dbm > > " > > ] > ] > > Crashes (one or more times, within 4–55 s): > > - key + signal (slash-projected) > - last_time + signal (slash-projected) > - signal + key (reversed order, same slash projection) > - key + last_time + signal (slash-projected, three fields, docs-example shape) > - key + last_time + leaf-only signal (kismet.common.signal.last_signal as > bare leaf) > - Leaf-only kismet.common.signal.last_signal alone > - Unrelated slash projection combined with flat fields: > key + last_time + kismet.device.base.location/kismet.common.location.avg_loc/kismet.common.location.geopoint > > Time-to-crash across the runs that crashed: > > 4.4 s, 6.3 s, 13.7 s, 17.0 s, 25.8 s, 31.0 s, 32.0 s, 33.5 s, 54.9 s, ~3.5 min > > — > Reply to this email directly, [view it on GitHub](#606), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFKJYYYA7IGDBQNYYZW35AT435AJDAVCNFSM6AAAAACZIB6JIOVHI2DSMVQWIX3LMV43ASLTON2WKOZUGQ4TMOBVGEYDIMI). > Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905) or [Android](https://play.google.com/store/apps/details?id=com.github.android). > You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> — Reply to this email directly, [view it on GitHub](#606 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAZAOCAPH4CFX24KIBR653T435CHFAVCNFSM6AAAAACZIB6JIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMJRGM2TONRRHE). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905) or [Android](https://play.google.com/store/apps/details?id=com.github.android). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>