Verify various IP header fields Check that no no extention headers (IPv6) are present Check that no IPv4 options are present
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 74914 Build 71797: arc lint + arc unit
Event Timeline
| sys/dev/irdma/irdma_utils.c | ||
|---|---|---|
| 1525 | Isn't this check redundant? The check below for iphlen != (iph->ip_hl << 2) will catch this case too: iphlen is either 20 or 40, so if iph->ip_hl < 5, then iph->ip_hl << 2 must be less than 20. | |
| sys/dev/irdma/irdma_utils.c | ||
|---|---|---|
| 1614 | Why isn't it necessary to patch this function as well? | |
| sys/dev/irdma/irdma_utils.c | ||
|---|---|---|
| 1525 | The issue is that iphlen is not extracted from the actual packets, but populated just by assuming the header is either IPv4 or IPv6; IP headers are variable length with IPv4. iph->ip_hl is the data extracted from the actual header. And with IPv6, one can use extention headers between the IP and TCP header, to dynamically shift the actual TCP (and iWARP) offset around. These are representing valid uses of IP, and while it is maybe possible the firmware filters this out, ensuring the conformaty in the slow path here seems prudent. | |
| 1614 | Fixed in D58323, thx. | |
| sys/dev/irdma/irdma_utils.c | ||
|---|---|---|
| 1523–1524 | Do we need to check that the received buffer is large enough to contain an IP header, before we start dereferencing iph? | |