[enricolorenzoni59]

Summary
decodeSbsLine() accepts fields 12 (baro altitude), 14 (heading) and 17 (vertical rate) when they are finite, and stores altitude and rate in int members. 1e308 is a finite double but far outside int, so the conversion is undefined.

Impact
With --net-sbs-in-port (or any SBS input/connector), a feeder that sends an out-of-range altitude or vertical rate puts 2147483647 into alt_baro/baro_rate in aircraft.json (and into the JSON/VRS outputs), and a UBSan build aborts. 1e308 also overflows the signed arithmetic in updateAltitude(). A heading of 361 or -5 is accepted as a valid track. The ground speed field has the same problem for 1e308, which was already bounded to 0..6000 kt.

Repro

MSG,3,1,1,4CA123,1,2026/01/01,00:00:00.000,2026/01/01,00:00:00.000,,1e308,,,51.5,-0.1,1e308,,4,1,,0

Before (release build), aircraft.json:

{"hex":"4ca123","alt_baro":2147483647,"baro_rate":2147483647,...}

Before (UBSan build):

net_io.c:3523:28: runtime error: 1e+308 is outside the range of representable values of type 'int'
net_io.c:3576:29: runtime error: 1e+308 is outside the range of representable values of type 'int'

and with a heading of 361 the aircraft reports "track": 361.

Fix
Require fabs(tmp) <= 100000 for altitude and vertical rate, and 0 <= heading <= 360, the same way the ground speed field already requires 0..6000 kt. An out-of-range field is marked invalid like any other parse failure; the rest of the record is still used.

Verification

• After the change the extreme altitude/rate record is accepted with those two fields invalid: alt_baro and baro_rate are absent from aircraft.json, the aircraft is still tracked, and no sanitizer report appears.
• A heading of 361 or -5 no longer produces a track; 0..360 still does.
• Valid values are unchanged: 35000 ft, -1216 ft/min, heading 90, ground speed 90 kt.