----------------------------------------------------------------------------------
@MSGID: 3:633/280 68e847d8
@CHRS: CP437 2
@TZUTC: 1100
@TID: hpt/lnx 1.9 2024-03-02
Hi Husky developers,
I`ve discovered a bug in HPT where packets with corrupted/empty message date
fields are not properly rejected and renamed to .bad as they should be.
PROBLEM DESCRIPTION:
===================
When processing packets, HPT reads the 20-byte datetime field from each
message header (pktread.c:771) and calls parse_ftsc_date() to parse it
(line 777). However, the return value from parse_ftsc_date() is ignored.
The parse_ftsc_date() function returns flag_t values indicating:
- FTSC_BROKEN (2) - field cannot be parsed
- FTSC_FLAWY (1) - field has correctable errors
- FTSC_TS_BROKEN (128) - timestamp broken but date OK
Currently, even when parse_ftsc_date() returns FTSC_BROKEN, the badmsg
counter is not incremented, so the packet is not renamed to .bad and
continues to be processed.
REAL-WORLD IMPACT:
==================
I encountered a packet in the wild (from 2:341/66) that contains:
- Message 3: Empty date field (0 bytes)
- Message 4: Invalid date field (1 byte: `0`)
The bad packet can be obtained at:
https://vk3heg.net/badpkt.zip
HPT processed this packet instead of rejecting it.
PROPOSED FIX:
=============
After calling parse_ftsc_date(), check if the FTSC_BROKEN flag is set and
increment badmsg accordingly. This ensures corrupted packets are properly
renamed to .bad.
Patch attached below. Please review and consider applying to the codebase.
--- hpt/src/pktread.c.orig 2025-10-09 10:00:00.000000000 +1100
+++ hpt/src/pktread.c 2025-10-09 10:05:00.000000000 +1100
@@ -734,6 +734,7 @@
{
s_message * msg;
size_t len;
+ flag_t date_flags;
int badmsg = 0;
struct tm tm;
long unread;
@@ -774,7 +775,16 @@
}
msg->datetime[20] = 0; /* ensure it`s null-terminated */
- parse_ftsc_date(&tm, (char *)msg->datetime);
+ date_flags = parse_ftsc_date(&tm, (char *)msg->datetime);
+
+ /* Check if the date field is broken and cannot be parsed */
+ if(date_flags & FTSC_BROKEN)
+ {
+ w_log(LL_ERR,
+ "wrong msg header: datetime field is broken (`%s`)",
+ msg->datetime);
+ badmsg++;
+ }
/* val: make_ftsc_date((char*)msg->datetime, &tm); */
if(globalBuffer == NULL)
TESTING:
========
With this patch applied, packets with broken date fields will be properly
rejected and renamed to .bad instead of being processed.
Best Regards,
Stephen
--- GoldED+/LNX 1.1.5-b20250409
* Origin: Dragon`s Lair ---:- dragon.vk3heg.net -:--- Prt: 6800 (3:633/280)
SEEN-BY: 19/10 50/109 103/705 104/117 124/5016
153/757 154/10 30 201/0 203/0
SEEN-BY: 218/840 221/0 1 6 360 229/426 240/1120
5832 263/1 280/464 5003 5006
SEEN-BY: 292/854 8125 301/1 310/31 320/219 335/364
341/66 234 396/45 423/81
SEEN-BY: 423/120 452/28 166 460/58 463/68 467/888
633/267 280 414 418 420 422
SEEN-BY: 633/509 2744 712/848 770/1 5000/111
5010/352 5015/46 5020/400 715
SEEN-BY: 5020/828 846 848 1042 4441 12000 5030/49
1081 5053/51 5061/133
SEEN-BY: 5075/128 5083/444
@PATH: 633/280 280/464 221/1 6 5020/1042 4441