iWARP handling code deals with TCP header processing outside of the normal TCP stack. Certain validation checks to verify the internal integrity of the TCP header were missing.
Details
Details
- Reviewers
tuexen markj kgalazka bartosz.sobczak_intel.com - Group Reviewers
Restricted Owners Package (Owns No Changed Paths) transport - Commits
- rGe0c6b88706a9: irdma: improve TCP header validation
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 74955 Build 71838: arc lint + arc unit
Event Timeline
Comment Actions
To whom it may concern: the same problem seems to exist in the Linux source code: cm.c.
| sys/dev/irdma/irdma_utils.c | ||
|---|---|---|
| 1544 | Indeed, missed the other occurance initially. | |
| sys/dev/irdma/irdma_cm.c | ||
|---|---|---|
| 837 | Why not make it an error? | |
| sys/dev/irdma/irdma_utils.c | ||
| 1544 | My second comment still stands: what's the purpose of checking th_off < 5 above? That case is already handled here and in irdma_puda_get_tcpip_info(). | |
| 1597 | I think you still need to check that this subtraction won't underflow? | |
Comment Actions
We find this change to be good enough. There is an incoming change in this area along with irdma 1.5.43 upgrade, that should close out the remaining loose ends.
| sys/dev/irdma/irdma_cm.c | ||
|---|---|---|
| 837 | That was discussed but would allow potential off-path attackers to terminate rdma sessions with just incorrect option length (and blind in-window attack guesswork) thus potentially opening a denial-of-service attack surface. Silently ignoring malformed packets would allow the legitimate packets to continue (the debug codepath taken will slow down processing though), | |
| 2679 | src shows <tab> in both instances; which appears to be the style in this source file. | |
| sys/dev/irdma/irdma_utils.c | ||
| 1544 | It appears to be different codepaths and catching malformed tcp fields early in some is desirable. I'm not intricately familiar with all codepath here though. | |
| 1597 | Arguably this is a more serverely malformed packet. This patch focuses on incorrect tcp header fields only. | |