Closed qingkaishi closed 2 years ago
Thanks again, fixed this by checking if packet_len
is at least as large as the header:
diff --git a/src/osdp_phy.c b/src/osdp_phy.c
index cd3cab0..083c008 100644
--- a/src/osdp_phy.c
+++ b/src/osdp_phy.c
@@ -296,7 +296,8 @@ int osdp_phy_check_packet(struct osdp_pd *pd, uint8_t *buf, int len,
return OSDP_ERR_PKT_WAIT;
}
- if (pkt_len > OSDP_PACKET_BUF_SIZE) {
+ if (pkt_len > OSDP_PACKET_BUF_SIZE ||
+ (unsigned long)pkt_len < sizeof(struct osdp_packet_header)) {
pd->reply_id = REPLY_NAK;
pd->ephemeral_data[0] = OSDP_PD_NAK_CMD_LEN;
return OSDP_ERR_PKT_NACK;
https://github.com/goToMain/libosdp/blob/a3eb794b4599094ab6d6c57b3117c2fafdb9a22e/src/osdp_phy.c#L292-L312
There is an overflow bug in the code above.
Line 293 reads the value of
pkt_len
from a message.Line 294 and Line 299 attempt to validate the packet length,
pkt_len
, which guarantees thatpkt_len <= min(len, OSDP_PACKET_BUF_SIZE)
Let us assume
pkt_len = 1
and reach Line 309,pkt_len-=2
leads topkt_len = -1
. At Line 311,pkt_len = -1
is passed into the functionosdp_compute_crc16
via the second parameter, which is of the typesize_t
, an unsigned integer type.Hence, in
osdp_compute_crc16
,pkt_len = -1
will be interpreted as a very large positive integer, thusbuf[pkt_len]
will overflow inosdp_compute_crc16
.The bug may be triggered by a malformed packet, and the above idea is validated by address sanitizer as follows:
possible fix
add a check
pkt_len >= 2
before Line 309add a check
pkt_len >= 1
before Line 319