diff options
author | Guy Harris <gharris@sonic.net> | 2022-01-26 15:00:26 -0800 |
---|---|---|
committer | Guy Harris <gharris@sonic.net> | 2022-01-26 15:00:26 -0800 |
commit | c60ebf10efd105d149f7c2d3eb15dec38af45001 (patch) | |
tree | 1a6eb5f1d7f84cf7451eb6847ec381f382e4119f /pcap-snit.c | |
parent | f570e6be7c5573f6e9310db751ede041a5e6151f (diff) |
Make sure no read routine process more than INT_MAX packets.
Some read routines don't read a single bufferful of packets and process
just those packets; if packets continue to be made available, they could
conceivably process an arbitrary number of packets.
That would mean that the packet count overflows; either that makes it
look like a negative number, making it look as if an error occurred, or
makes it look like a too-small positive number.
This can't be fixed by making the count 64-bit, as it ultimately gets
returned by pcap_dispatch(), which is defined to return an int.
Instead, if the maximum packet count argument to those routines is a
value that means "no maximum", we set the maximum to INT_MAX. Those
routines are *not* defined to loop forever, so this isn't an issue.
This should fix issue #1087.
Diffstat (limited to 'pcap-snit.c')
-rw-r--r-- | pcap-snit.c | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/pcap-snit.c b/pcap-snit.c index ca6222cf..ff0cb59a 100644 --- a/pcap-snit.c +++ b/pcap-snit.c @@ -139,6 +139,9 @@ pcap_read_snit(pcap_t *p, int cnt, pcap_handler callback, u_char *user) /* * loop through each snapshot in the chunk + * + * This assumes that a single buffer of packets will have + * <= INT_MAX packets, so the packet count doesn't overflow. */ n = 0; ep = bp + cc; |