summaryrefslogtreecommitdiff
path: root/external/bsd/jemalloc/dist/doc/jemalloc.3
diff options
context:
space:
mode:
authorrillig <rillig@NetBSD.org>2023-07-09 10:42:07 +0000
committerrillig <rillig@NetBSD.org>2023-07-09 10:42:07 +0000
commit61a832267cc5bff1a90f086bd56309a3a0671255 (patch)
tree6f663ed82c04970fa2f72561dc8eb6681e5f29fe /external/bsd/jemalloc/dist/doc/jemalloc.3
parentb2782b14a8e5066f0436d79a391ce49f9e782b76 (diff)
lint: remove redundant '#' after 'argument' in diagnosticsHEADtrunk
Diffstat (limited to 'external/bsd/jemalloc/dist/doc/jemalloc.3')
0 files changed, 0 insertions, 0 deletions
>maxv to the same IPsec processing. That is to say, that all fragments are ESP, or AH, or AH+ESP, or none. The reassembly mechanism can be used both on the wire and inside an IPsec tunnel, so we need to make sure all fragments of a packet were received on only one side. Even though I haven't tried, I believe there are configurations where it would be possible for an attacker to inject an unencrypted fragment into a legitimate stream of already-decrypted-and-authenticated fragments. Typically on IPsec gateways with ESP tunnels, where we can encapsulate fragments (as opposed to the general case, where we fragment encapsulated data). Note, for the record: a funnier thing, under IPv4, would be to send a zero-sized !MFF fragment at the head of the packet, and manage to trigger an ICMP error; M_DECRYPTED gets lost by the reassembly, and ICMP will reply with the packet in clear (not encrypted). 2018-05-03Rename m_pkthdr_remove -> m_remove_pkthdr, to match the existing namingmaxv convention, eg m_copy_pkthdr and m_move_pkthdr. 2018-04-11Add 'static', like the prototype.maxv 2018-03-09Remove M_PKTHDR from secondary mbufs when reassembling packets.maxv This is a real problem, because I found at least one component that relies on the fact that only the first mbuf has M_PKTHDR: far from here, in m_splithdr, we don't update m->m_pkthdr.len if M_PKTHDR is found in a secondary mbuf. (The initial intention there was to avoid updating m_pkthdr.len twice, the assumption was that if M_PKTHDR is set then we're dealing with the first mbuf.) Therefore, when handling fragmented IPsec packets (in particular IPv6, IPv4 is a bit more complicated), we may end up with an incorrect m_pkthdr.len after authentication or decryption. In the case of ESP, this can lead to a remote crash on this instruction: m_copydata(m, m->m_pkthdr.len - 3, 3, lastthree); m_pkthdr.len is bigger than the actual mbuf chain. It seems possible to me to trigger this bug even if you don't have the ESP key, because the fragmentation part is outside of the encrypted ESP payload. So if you MITM the target, and intercept an incoming ESP packet (which you can't decrypt), you should be able to forge a new specially-crafted, fragmented packet and stuff the ESP payload (still encrypted, as you intercepted it) into it. The decryption succeeds and the target crashes. 2018-02-08Change the error stat from IP_STAT_BADFRAGS to IP_STAT_TOOLONG. Themaxv ping_of_death ATF test expects this counter to get increased. 2018-02-06Add one more check in ip_reass_packet(): make sure that the end of eachmaxv fragment does not exceed IP_MAXPACKET. In ip_reass(), we only check the final length of the reassembled packet against IP_MAXPACKET. But there is an integer overflow that can happen a little earlier. We are doing: i = ntohs(p->ipqe_ip->ip_off) + ntohs(p->ipqe_ip->ip_len) - ntohs(ip->ip_off); [...] ip->ip_off = htons(ntohs(ip->ip_off) + i); It is possible that ntohs(p->ipqe_ip->ip_off) + ntohs(p->ipqe_ip->ip_len) > 65535 so the computation of ip_off wraps to zero. This breaks an assumption in the reassembler - it expects the list of fragments to be ordered by offset, and here it's not ordered anymore. (Un)Fortunately I couldn't turn this into anything exploitable. With the new check, it is guaranteed that ip_off+ip_len<=65535. 2017-01-11Get rid of unnecessary header inclusionsozaki-r 2016-04-26Sweep unnecessary route.h inclusionsozaki-r 2014-02-25Ensure that the top level sysctl nodes (kern, vfs, net, ...) exist beforepooka the sysctl link sets are processed, and remove redundancy. Shaves >13kB off of an amd64 GENERIC, not to mention >1k duplicate lines of code. 2011-06-27Don't increment ip_nfragpackets when failed to allocate fragment queue.enami No one will decrement it on such case. 2010-11-05ip_reass_packet: finish abstraction; some clean-up.rmind Discussed some time ago with matt@. 2010-10-07make ipfr_lock IPL_VM as ip_reass_drain is called in interrupts viayamt the drain hook for mbuf pools. 2010-10-06Don't free memory still in use. Fixes nfs root problem reportedenami by Christoph Egger on source-changes-d. 2010-10-03Re-structure IPv4 reassembly code to make it more MP-friendly and simplifyrmind some code fragments while here. Also, use pool_cache(9) and mutex(9). IPv4 reassembly mechanism is MP-safe now. 2010-08-25Use own IPv4 reassembly queue entry structure and leave struct ipqent onlyrmind for TCP. Now both struct ipfr_qent, struct ipfr_queue and hashed fragment queue are abstracted and no longer public. 2010-07-19Abstract IP reassembly into single generic routine - ip_reass_packet().rmind Make struct ipq private and struct ipqent not visible to userland. Push ip_len adjustment into reassembly layer. OK matt@ 2010-07-13Split-off IPv4 re-assembly mechanism into a separate module. Abstractrmind into ip_reass_init(), ip_reass_lookup(), etc (note: abstraction is not yet complete). No functional changes to the actual mechanism. OK matt@