tcp: Incorrect KASSERT causes a panic in rack

Skyzall found an interesting panic in rack. When a SYN and FIN are
both sent together a KASSERT gets tripped where it is validating that
a mbuf pointer is in the sendmap. But a SYN and FIN often will not
have a mbuf pointer. So the fix is two fold a) make sure that the
SYN and FIN split the right way when cloning an RSM SYN on left
edge and FIN on right. And also make sure the KASSERT properly
accounts for the case that we have a SYN or FIN so we don't
panic.

Reviewed by: mtuexen
Sponsored by: Netflix Inc.
Differential Revision:	https://reviews.freebsd.org/D30241
This commit is contained in:
Randall Stewart 2021-05-13 07:36:04 -04:00
parent 8ea5eeb913
commit 02cffbc250

View File

@ -6054,6 +6054,12 @@ rack_clone_rsm(struct tcp_rack *rack, struct rack_sendmap *nrsm,
for (idx = 0; idx < nrsm->r_rtr_cnt; idx++) {
nrsm->r_tim_lastsent[idx] = rsm->r_tim_lastsent[idx];
}
/* Now if we have SYN flag we keep it on the left edge */
if (nrsm->r_flags & RACK_HAS_SYN)
nrsm->r_flags &= ~RACK_HAS_SYN;
/* Now if we have a FIN flag we keep it on the right edge */
if (nrsm->r_flags & RACK_HAS_FIN)
nrsm->r_flags &= ~RACK_HAS_FIN;
/*
* Now we need to find nrsm's new location in the mbuf chain
* we basically calculate a new offset, which is soff +
@ -6061,9 +6067,11 @@ rack_clone_rsm(struct tcp_rack *rack, struct rack_sendmap *nrsm,
* chain to find the righ postion, it may be the same mbuf
* or maybe not.
*/
KASSERT((rsm->m != NULL),
KASSERT(((rsm->m != NULL) ||
(rsm->r_flags & (RACK_HAS_SYN|RACK_HAS_FIN))),
("rsm:%p nrsm:%p rack:%p -- rsm->m is NULL?", rsm, nrsm, rack));
rack_setup_offset_for_rsm(rsm, nrsm);
if (rsm->m)
rack_setup_offset_for_rsm(rsm, nrsm);
}
static struct rack_sendmap *