В ядре Linux устранена следующая уязвимость:
mptcp: fastopen: отмечать только подпотоки MPTFO с данными SYN
Пассивный TCP Fast Open принимает SYN действительных файлов cookie, даже если он содержит
нет данных. В этом случае очередь приема дочернего сокета намеренно
осталось пустым.
mptcp_fastopen_subflow_synack_set_params() устанавливает is_mptfo перед проверкой
для данных SYN в очереди. Это привело к тому, что TFO SYN без данных попали в предупреждение, и, если
предупреждение не было фатальным, оставив устаревшее состояние MPTFO позади. несвежий
флаг может позже вызвать ошибку, приводящую к путанице состояний в
проверить_полностью_установлен().
Отмечайте подпоток как MPTFO только после подтверждения того, что SKB поставлен в очередь. Вернитесь спокойно, когда очередь приема пуста. Обратите внимание, что поле is_mptfo в mptcp_subflow_context теперь не просто
подпотоки, где присутствовал TFO, а о подпотоке MPTFO, который
потребляемые данные SYN.
Только наличие действующего файла cookie, но не переносящего данные, является на самом деле не «делаю TFO».
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: mptcp: fastopen: only mark MPTFO subflows with SYN data Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty. mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in check_fully_established(). Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty. Note that mptcp_subflow_context's is_mptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really "doing TFO".