{"push_id":920622239,"size":1,"distinct_size":1,"ref":"refs/heads/M","head":"386dfd7de882442f48f14eb20bdb7081f1328751","before":"178291f29ec88f32ebc7e12ef210d2a34d74c912","commits":[{"sha":"386dfd7de882442f48f14eb20bdb7081f1328751","author":{"email":"f34fa9a6ed7f70238faacc0289802dd5d831b64e@fb.com","name":"Calvin Owens"},"message":"tcp: Restore RFC5961-compliant behavior for SYN packets\n\nCommit c3ae62af8e755 (\"tcp: should drop incoming frames without ACK\nflag set\") was created to mitigate a security vulnerability in which a\nlocal attacker is able to inject data into locally-opened sockets by\nusing TCP protocol statistics in procfs to quickly find the correct\nsequence number.\n\nThis broke the RFC5961 requirement to send a challenge ACK in response\nto spurious RST packets, which was subsequently fixed by commit\n7b514a886ba50 (\"tcp: accept RST without ACK flag\").\n\nUnfortunately, the RFC5961 requirement that spurious SYN packets be\nhandled in a similar manner remains broken.\n\nRFC5961 section 4 states that:\n\n   ... the handling of the SYN in the synchronized state SHOULD be\n   performed as follows:\n\n   1) If the SYN bit is set, irrespective of the sequence number, TCP\n      MUST send an ACK (also referred to as challenge ACK) to the remote\n      peer:\n\n      <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>\n\n      After sending the acknowledgment, TCP MUST drop the unacceptable\n      segment and stop processing further.\n\n   By sending an ACK, the remote peer is challenged to confirm the loss\n   of the previous connection and the request to start a new connection.\n   A legitimate peer, after restart, would not have a TCB in the\n   synchronized state.  Thus, when the ACK arrives, the peer should send\n   a RST segment back with the sequence number derived from the ACK\n   field that caused the RST.\n\n   This RST will confirm that the remote peer has indeed closed the\n   previous connection.  Upon receipt of a valid RST, the local TCP\n   endpoint MUST terminate its connection.  The local TCP endpoint\n   should then rely on SYN retransmission from the remote end to\n   re-establish the connection.\n\nThis patch lets SYN packets through the discard added in c3ae62af8e755,\nso that spurious SYN packets are properly dealt with as per the RFC.\n\nThe challenge ACK is sent unconditionally and is rate-limited, so the\noriginal vulnerability is not reintroduced by this patch.\n\nSigned-off-by: Calvin Owens <calvinowens@fb.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\nAcked-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Ravikumar Vembu <a18394@motorola.com>\nChange-Id: Ifb286ad548908c1b59783860163773df6f0f3670\nReviewed-on: http://gerrit.mot.com/693006\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nReviewed-by: Ravikumar Vembu <raviv@motorola.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Starship-Android/starship_kernel_moto_shamu/commits/386dfd7de882442f48f14eb20bdb7081f1328751"}]}