--- /dev/null
+From: Jeffrey Altman <jaltman@your-file-system.com>
+Date: Thu, 8 Oct 2015 22:22:12 -0400
+Subject: rx: CVE-2015-7762 and CVE-2015-7763
+
+CVE-2015-7762:
+
+The CMU/Transarc/IBM definition of rx_AckDataSize(nAcks) was mistakenly
+computed from sizeof(struct rx_ackPacket) and inadvertently added three
+octets to the computed ack data size. When constructing ack packets
+these three octets were not assigned a value but were written to the
+network.
+
+Beginning with AFS 3.3, IBM extended the ACK packet with the "maxMTU" ack
+trailer value which was appended to the packet according to the
+rx_AckDataSize() computation. As a result the three unassigned octets
+were unintentionally cemented into the ACK packet format.
+
+In OpenAFS commit 4916d4b4221213bb6950e76dbe464a09d7a51cc3 Nickolai
+Zeldovich <kolya@mit.edu> noticed that the size produced by the
+rx_AckDataSize(nAcks) macro was dependent upon the compiler and processor
+architecture. The rx_AckDataSize() macro was altered to explicitly
+expose the three octets that are included in the computation.
+Unfortunately, the failure to initialize the three octets went unnoticed.
+
+The Rx implementation maintains a pool of packet buffers that are reused
+during the lifetime of the process. When an ACK packet is constructed
+three octets from a previously received or transmitted packets will be
+leaked onto the network. These octets can include data from a
+received packet that was encrypted on the wire and then decrypted.
+
+If the received encrypted packet is a duplicate or if it is outside the
+valid window, the decrypted packet will be used immediately to construct
+an ACK packet.
+
+CVE-2015-7763
+
+In OpenAFS commit c7f9307c35c0c89f7ec8ada315c81ebc47517f86 the ACK packet
+was further extended in an attempt to detect the path MTU between two
+peers. When the ACK reason is RX_ACK_PING a variable number of octets is
+appended to the ACK following the ACK trailers.
+
+The implementation failed to initialize all of the padding region.
+A variable amount of data from previous packets can be leaked onto the
+network. The padding region can include data from a received packet
+that was encrypted on the wire and then decrypted.
+
+OpenAFS 1.5.75 through 1.5.78 and all 1.6.x releases (including release
+candidates) are vulnerable.
+
+Credits:
+
+ Thanks to John Stumpo for identifying both vulnerabilities.
+
+ Thanks to Simon Wilkinson for patch development.
+
+ Thanks to Ben Kaduk for managing the security release cycle.
+
+Change-Id: I29e47610e497c0ea94033450f434da11c367027c
+(Cherry-picked from a pre-release version of the patch)
+---
+ src/rx/rx.c | 31 +++++++++++++++++++++----------
+ 1 file changed, 21 insertions(+), 10 deletions(-)
+
+diff --git a/src/rx/rx.c b/src/rx/rx.c
+index 5810527..1fc7a20 100644
+--- a/src/rx/rx.c
++++ b/src/rx/rx.c
+@@ -5508,6 +5508,9 @@ rxi_ResetCall(struct rx_call *call, int newcall)
+ int reason; Reason an acknowledge was prompted
+ */
+
++#define RX_ZEROS 1024
++static char rx_zeros[RX_ZEROS];
++
+ struct rx_packet *
+ rxi_SendAck(struct rx_call *call,
+ struct rx_packet *optionalPacket, int serial, int reason,
+@@ -5663,6 +5666,11 @@ rxi_SendAck(struct rx_call *call,
+ ap->nAcks = offset;
+ p->length = rx_AckDataSize(offset) + 4 * sizeof(afs_int32);
+
++ /* Must zero the 3 octets that rx_AckDataSize skips at the end of the
++ * ACK list.
++ */
++ rx_packetwrite(p, rx_AckDataSize(offset) - 3, 3, rx_zeros);
++
+ /* these are new for AFS 3.3 */
+ templ = rxi_AdjustMaxMTU(call->conn->peer->ifMTU, rx_maxReceiveSize);
+ templ = htonl(templ);
+@@ -5681,6 +5689,8 @@ rxi_SendAck(struct rx_call *call,
+ rx_packetwrite(p, rx_AckDataSize(offset) + 3 * sizeof(afs_int32),
+ sizeof(afs_int32), &templ);
+
++ p->length = rx_AckDataSize(offset) + 4 * sizeof(afs_int32);
++
+ p->header.serviceId = call->conn->serviceId;
+ p->header.cid = (call->conn->cid | call->channel);
+ p->header.callNumber = *call->callNumber;
+@@ -5694,19 +5704,20 @@ rxi_SendAck(struct rx_call *call,
+ #ifdef ADAPT_WINDOW
+ clock_GetTime(&call->pingRequestTime);
+ #endif
+- if (padbytes) {
+- p->length = padbytes +
+- rx_AckDataSize(call->rwind) + 4 * sizeof(afs_int32);
++ }
+
+- while (padbytes--)
+- /* not fast but we can potentially use this if truncated
+- * fragments are delivered to figure out the mtu.
+- */
+- rx_packetwrite(p, rx_AckDataSize(offset) + 4 *
+- sizeof(afs_int32), sizeof(afs_int32),
+- &padbytes);
++ while (padbytes > 0) {
++ if (padbytes > RX_ZEROS) {
++ rx_packetwrite(p, p->length, RX_ZEROS, rx_zeros);
++ p->length += RX_ZEROS;
++ padbytes -= RX_ZEROS;
++ } else {
++ rx_packetwrite(p, p->length, padbytes, rx_zeros);
++ p->length += padbytes;
++ padbytes = 0;
+ }
+ }
++
+ if (call->conn->type == RX_CLIENT_CONNECTION)
+ p->header.flags |= RX_CLIENT_INITIATED;
+