---
- branch: netbsd-8
  date: Thu Apr  5 14:33:42 UTC 2018
  files:
  - new: 1.172.6.2
    old: 1.172.6.1
    path: src/sys/kern/uipc_mbuf.c
    pathrev: src/sys/kern/uipc_mbuf.c@1.172.6.2
    type: modified
  - new: 1.11.8.2
    old: 1.11.8.1
    path: src/sys/netinet/ip_reass.c
    pathrev: src/sys/netinet/ip_reass.c@1.11.8.2
    type: modified
  - new: 1.60.6.4
    old: 1.60.6.3
    path: src/sys/netinet6/frag6.c
    pathrev: src/sys/netinet6/frag6.c@1.60.6.4
    type: modified
  - new: 1.170.2.3
    old: 1.170.2.2
    path: src/sys/sys/mbuf.h
    pathrev: src/sys/sys/mbuf.h@1.170.2.3
    type: modified
  id: 20180405T143342Z.6029b5f33b616b3e2eeaacb22c0db9d73fa3053f
  log: "Pull up following revision(s) (requested by maxv in ticket #695):\n\n\tsys/kern/uipc_mbuf.c:
    revision 1.182\n\tsys/netinet6/frag6.c: revision 1.67\n\tsys/netinet/ip_reass.c:
    revision 1.14\n\tsys/sys/mbuf.h: revision 1.179\n\nRemove M_PKTHDR from secondary
    mbufs when reassembling packets.\n\nThis is a real problem, because I found at
    least one component that relies\non the fact that only the first mbuf has M_PKTHDR:
    far from here, in\nm_splithdr, we don't update m->m_pkthdr.len if M_PKTHDR is
    found in a\nsecondary mbuf. (The initial intention there was to avoid updating\nm_pkthdr.len
    twice, the assumption was that if M_PKTHDR is set then we're\ndealing with the
    first mbuf.) Therefore, when handling fragmented IPsec\npackets (in particular
    IPv6, IPv4 is a bit more complicated), we may end\nup with an incorrect m_pkthdr.len
    after authentication or decryption. In\nthe case of ESP, this can lead to a remote
    crash on this instruction:\n        m_copydata(m, m->m_pkthdr.len - 3, 3, lastthree);\nm_pkthdr.len
    is bigger than the actual mbuf chain.\n\nIt seems possible to me to trigger this
    bug even if you don't have the ESP\nkey, because the fragmentation part is outside
    of the encrypted ESP\npayload.\n\nSo if you MITM the target, and intercept an
    incoming ESP packet (which you\ncan't decrypt), you should be able to forge a
    new specially-crafted,\nfragmented packet and stuff the ESP payload (still encrypted,
    as you\nintercepted it) into it. The decryption succeeds and the target crashes.\n"
  module: src
  subject: 'CVS commit: [netbsd-8] src/sys'
  unixtime: '1522938822'
  user: martin