bcmxcp driver crashes with stack smashing on Eaton Power Xpert 9395 during ID block parsing

[proPonent]

Summary

The bcmxcp driver in NUT 2.8.5 crashes immediately after successfully connecting to an Eaton Power Xpert 9395 UPS over RS232.

The crash is reproducible and appears to occur while parsing the UPS ID/capability response after the initial 0xA0 identification request.

This looks like a buffer overflow or parser size assumption issue in the driver.

---

Environment

• NUT version: 2.8.5
• Driver: bcmxcp 0.39
• OS: Arch/CachyOS Linux
• Architecture: x86_64
• Compiler: GCC 15.2.1
• Transport: RS232 /dev/ttyS0
• UPS: Eaton Power Xpert 9395
• Baudrate: 19200 autodetected successfully

---

Driver Output

Network UPS Tools 2.8.5 release - BCMXCP UPS driver 0.39
RS-232 communication subdriver 0.22

Attempting to autodect baudrate

send_command: (7 bytes) => ab 04 cf 69 e8 d5 5c
send_command: (4 bytes) => ab 01 a0 b4

Connected to UPS on /dev/ttyS0 with baudrate 19200

*** stack smashing detected ***: terminated

---

systemd-coredump Output

*** stack smashing detected ***: terminated

#0  pthread_kill
#1  raise
#2  abort
#3  __fortify_fail
#4  __stack_chk_fail
#5  /usr/lib/nut/bcmxcp +0x949a
#6  /usr/lib/nut/bcmxcp +0x4fcd

---

Additional Investigation

The UPS responds correctly to the standard BCM/XCP authorization block and ID request using a custom Python script.

The following requests are sent successfully:

AUTH:
ab 04 cf 69 e8 d5 5c

GET_ID:
ab 01 a0 b4

The UPS returns a large multi-frame response containing the ASCII identifier:

POWER XPERT 9395

Actual response from ups from custom python script:

❯ ./id.py
Opening /dev/ttyS0 at 19200
Sending ESC...
Sending AUTH block...
Requesting ID block...
RX (287 bytes)
ab 01 79 01 16 12 02 12 02 12 02 00 00 16 01 00 02 34 01 14 01 00 02 34 01 12 02 00 02 34 01 00 00 00 00 00 00 00 00 00 00 00 00 34 01 01 00 01 00 00 f8 2a 03 78 14 50 4f 57 45 52 20 58 50 45 52 54 20 39 33 39 35 20 20 20 20 84 51 51 51 51 51 51 00 00 00 51 51 51 00 00 00 00 00 00 51 51 51 70 70 70 70 53 53 51 51 00 51 00 51 51 50 e2 00 00 00 00 00 00 00 00 00 00 00 51 51 e2 ab 01 53 02 51 00 00 00 51 51 51 51 51 51 00 00 00 51 00 00 51 51 51 51 51 51 00 e0 e1 00 00 00 00 51 51 51 51 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 51 51 51 51 51 51 51 51 51 51 51 51 00 00 00 00 00 00 00 f3 51 51 51 e7 ab 01 2f 03 2e ff df ff ff df ff a9 cf f9 df 53 0e c0 bf f0 df fd c3 20 a0 ff 03 02 92 8f 7f 0f fa b3 40 df fe 78 00 00 00 00 00 00 00 00 00 00 00 00 20 a6 ab 01 10 84 50 00 00 00 00 00 00 03 00 40 18 00 00 00 ab 00 6a

The first frame alone reports a payload length of 0x79 (121 bytes).

This suggests the crash may be caused by:

• fixed-size stack buffers
• assumptions about single-frame ID responses
• assumptions about older/smaller firmware capability blocks

---

Notes

The protocol itself appears functional:

• serial comms work
• auth works
• checksum validation appears correct
• UPS responds consistently

The crash occurs only after successful identification and likely during response parsing.

This may affect newer Eaton / Power Xpert firmware families that return extended capability or topology data.

---

Reproduction

sudo /usr/lib/nut/bcmxcp -DDDD -a eaton

ups.conf:

[eaton]
driver = bcmxcp
port = /dev/ttyS0
desc = "Eaton UPS"

[jimklimov]

One thing that comes to mind after a cursory look in the code is PW_ANSWER_MAX_SIZE defined to be 256, while your example above claims RX of 287 bytes. Maybe that is it or is not, you can check with a custom build of NUT to decide about further steps - see https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests