--nextPart1556021.3W6127AYXQ
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit
Hi Folks,
The attached patch fixes panics in tcp_input() / udp_input() when
an esp/transport mode is used _with_ cbc-block encryption.
Both tcp_input and udp_input assume that that full ip/tcp or ip/udp
header is in the first mbuf.
When esp w. block encryption is used, this wasn't the case, as
esp_cbc_decrypt() (called from esp4_input) was allocating a
new mbuf and decrypting it's payload into that mbuf, leaving
only the IP part of the header in the first mbuf.
The attached patch back-copies the decrypted payload back into
the first mbuf, and blows away the copy mbuf. This appears to
be a safe thing to do because the decrypted payload is
the same size as the original payload.
I'm not sure how this worked before (tried it in 4.9 and it
works somehow), or when it broke, but it's nothing if not
nasty. :) :)
Andrew.
--nextPart1556021.3W6127AYXQ
Content-Type: text/x-diff; name="esp_core.c.diff"
Content-Transfer-Encoding: 8Bit
Content-Disposition: attachment; filename="esp_core.c.diff"
--- sys.old/netinet6/esp_core.c 2004-10-13 17:34:10.000000000 -0400
+++ sys/netinet6/esp_core.c 2004-10-13 17:35:20.000000000 -0400
@@ -765,7 +765,26 @@
m_freem(scut->m_next);
scut->m_len = scutoff;
- scut->m_next = d0;
+ if ( d0 ) {
+ /*
+ * tcp_input/udp_input want the entire packet header
+ * to be in the same, first mbuf.
+ *
+ * To accomplish this we need to copy back the decrypted
+ * contents of d0 into the original mbuf. We know it will
+ * fit because it fit in its encrypted form.
+ *
+ * Once that's done we can destroy d0.
+ */
+ bcopy( mtod(d0, u_int8_t *),
+ mtod(scut, u_int8_t *) + scutoff, d0->m_len );
+ scut->m_len += d0->m_len; /* adjust length */
+ scut->m_next = d0->m_next;/* link in d0's chain */
+ d0->m_next = 0; /* isolate d0 */
+ m_freem(d0); /* free d0 */
+ } else {
+ scut->m_next = 0; /* no d0, so no chain */
+ }
/* just in case */
bzero(iv, sizeof(iv));
--nextPart1556021.3W6127AYXQ--