Remove old Allwinner port.

(jmcneill)

Remove the ipre_mlast field and the TRAVERSE macro.

The goal was to store in ipre_mlast the last mbuf of the chain, so that
m_cat could be called on it. But it's not needed, since m_cat already
does the equivalent of TRAVERSE itself.

If it were needed, there would be a bug, since we don't call TRAVERSE on
ipre_mlast when creating a new reassembly entry.

(maxv)

Avoid rounding errors for timeout values.

(mlelstv)

Remove unused field, and sync comment with reality.

(maxv)

expose pmf debug switches with sysctl.

(mlelstv)

limits are bytes, vm sizes are clicks.

(mlelstv)

Re-evaluate drive selection to catch hog-plug devices.

(mlelstv)

Delete a leading space (` ').

Noticed via `NetBSD Code Changes' RSS feed that merged the last two news
entries.

(leot)

Remove the call to vfp_fpscr_handler() from vfp_handler(). It actually never
avoids a full FPU switch, and costs a function call and a few tests.

Discussed on port-arm@ on october 2017:
http://mail-index.netbsd.org/port-arm/2017/10/16/msg004411.html

(bouyer)

Move NPF's todo list into src/doc/TODO.npf, and add some entries. After a
conversation (two months ago) with rmind and sborrill.

(maxv)

tickets 698-705

(snj)

Pull up following revision(s) (requested by maxv in ticket #705):
sys/arch/amd64/amd64/trap.c: 1.113
Mmh. We shouldn't read %cr2 here. %cr2 is initialized by the CPU only
during page faults (T_PAGEFLT), so here we're reading a value that comes
from a previous page fault.
That's a real problem; if you launch an unprivileged process, set up a
signal handler, make it sleep 10 seconds, and trigger a T_ALIGNFLT fault,
you get in si_addr the address of another LWP's page - and perhaps this
can be used to defeat userland ASLR.
This bug has been there since 2003.

(snj)

Pull up following revision(s) (requested by mlelstv in ticket #704):
sys/arch/evbarm/rpi/rpi_machdep.c: 1.81
Firmware after May 8, 2017 places APs in WFE state at boot. Add a "sev"
after writing the start vector, otherwise secondary CPUs will not boot.

(snj)

Pull up following revision(s) (requested by mlelstv in ticket #703):
sys/dev/scsipi/st.c: 1.234
sys/dev/scsipi/stvar.h: 1.26
Use separate lock to protect internal state and release locks when
calling biodone.

(snj)

Pull up following revision(s) (requested by hannken in ticket #702):
sys/miscfs/procfs/procfs_vnops.c: 1.203
Lock the target cwdi and take an additional reference to the
vnode we are interested in to prevent it from disappearing
before getcwd_common().
Should fix PR kern/53096 (netbsd-8 crash on heavy disk I/O)

(snj)

Pull up following revision(s) (requested by ozaki-r in ticket #701):
sys/netinet/in.c: 1.227
sys/netinet6/in6.c: 1.265
tests/net/arp/t_arp.sh: 1.35-1.36
Make GARP work again when DAD is disabled
The change avoids setting an IP address tentative on initializing it when
the IPv4 DAD is disabled (net.inet.ip.dad_count=0), which allows a GARP packet
to be sent (see arpannounce).  This is the same behavior of NetBSD 7, i.e.,
before introducing the IPv4 DAD.
Additionally do the same change to IPv6 DAD for consistency.
The change is suggested by roy@
--
Improve packet checks and error reporting
--
Add tests for GARP without DAD
Additionally make the existing tests for GARP more explicit.

(snj)

Pull up following revision(s) (requested by nonaka in ticket #700):
sys/dev/acpi/acpi_mcfg.c: 1.6
Change the iteration, to make sure the ACPI_MCFG_ALLOCATION structure we're
reading fits the table we allocated. Linux does the same.
I have a laptop which, for some reason, reports a table size of 62 bytes.
Clearly that's incorrect, it should be 60 (44 + 16). Because of the stray
+2, here the kernel reads past the end of the allocated buffer, hits an
unmapped VA, and panics at boot time. So the laptop can't boot.
Now it boots fine.

(snj)

Pull up following revision(s) (requested by christos in ticket #699):
bin/ed/ed.1: 1.32-1.33
bin/ed/main.c: 1.29
usr.bin/patch/pch.c: 1.29
Pass -S to ed(1) so that patches containing ! commands don't run commands.
Real cause of CVE-2018-0492:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894667)
--
add -S to disable ! commands.
--
Fix date.

(snj)

fix date

(snj)

Pull up following revision(s) (requested by joerg in ticket #698):
external/gpl3/binutils/dist/bfd/elflink.c: 1.14
When trying to decide the status of a weak symbol, resolve any
indirectness first. In the case of various Qt5 libraries, __bss_start
ends up with a Qt5 version, but it has to be resolved first to match the
actual (implicit) definition. This fixes the root cause of pkg/53089.

(snj)

Fix bug I introduced in previous commit.

(maxv)

add a Makefile

(christos)

turn on GCC spectre v2 mitigation options.

XXX: amd64 ALL doesn't build for me right now

(mrg)

update bind and dhcp

(christos)

moved dhcp to mpl

(christos)

add mpl

(christos)

sync our changes.

(christos)

now mpl

(christos)

Add build glue.

(christos)

merge 9.7.10

(christos)

fix the grep pattern for inside a makefile.  fixes build issue
reported by thorpej on tech-toolchain - we both found the same
fix around the same time.

XXX: kamil says solaris-type hosts will fail here as they need
XXX: 'egrep' not 'grep -E'.

(mrg)

switch vax to GCC 6.  thanks to Krister and Maya for the fixes.
it now appears as disfunctional as GCC 5 for vax.  ok ragge@.

this was the final GCC 5 platform in -current.  hooray!

(mrg)

new dhcp

(christos)

merge dhcp-4.4.1

(christos)

actually do what the previous change said:
don't turn on the new 'SPECTRE_V2_GCC_MITIGATION' option yet.

(mrg)

add an SPECTRE_V2_GCC_MITIGATION option to x86 kernels, that turns
on the GCC spectre v2 mitigation options.

XXX: pullup-8.
XXX: turn on in all kernels.

(mrg)

fix and use the macro.

(christos)

show how to turn on debugging.

(christos)

put back handling for SIOCGIFAFLAG_IN -- should not matter.

(christos)

When we advertise interfaces, don't skip if we are not autotargetting services
yet. It is the chicken and the egg problem.

(christos)

Allow overriding checking for debug functions

(christos)

Move sunxidep to pass5, it has to attach before simplefb

(bouyer)

Enable the display engine devices. Note that even if they attaches,
they will be active only if a proper display engine pipeline entry
is present in the device tree.

(bouyer)

Allow the graphic driver to be the kernel's console.
Match either from the allwinner,pipeline entry in the simple-framebuffer
fdt entry, or from console= from the command line.
console=fb0 and console=fb1 selects display backend unit 0 or 1 respectively;
console=fb selects the first activated display backend.

(bouyer)

Handle 'console=serial' passed from the bootargs. ok jmcneill@

(bouyer)

Allow to remove entries from the fdt, either by handle or
by compatible string. Proposed on tech-kern and port-arm, ok jmcneill@

(bouyer)

new acpica

(christos)

Merge conflicts; STA methods and fields are not present anymore.

(christos)

function grew an extra argument now.

(christos)

Remove dead code.

(maxv)

Lock the target cwdi and take an additional reference to the
vnode we are interested in to prevent it from disappearing
before getcwd_common().

Should fix PR kern/53096 (netbsd-8 crash on heavy disk I/O)

(hannken)

Fix typo

(ozaki-r)

Fix an inverted logic.

nbuf_cksum_barrier returns true when the direction is PFIL_OUT and TSO is
active; that is to say, it returns true when the checksum was already
recomputed by the function.

The check should be !nbuf_cksum_barrier, because otherwise we're wrongfully
checksumming twice, and it causes the packet to be kicked later in
tcp_input.

This can be seen with a configuration of the type:

procedure "norm" {
normalize: "max-mss" 15000
}
group default {
pass all apply "norm"
}

The packets systematically get dropped because the checksum validation in
tcp_input fails. With this patch in place, it works.

(maxv)

Rewrite npf_fetch_tcpopts:

* Instead of doing several nbuf_advance/nbuf_ensure_contig and
  playing with gotos, fetch the TCP options only once, and iterate over
  the (safe) area. The code is similar to tcp_dooptions.

* When handling TCPOPT_MAXSEG and TCPOPT_WINDOW, ensure the length is
  the one we're expecting. If it isn't, then skip the option. This
  wasn't done before, and not doing it allowed a packet to bypass the
  max-mss clamping procedure. Discussed on tech-net@.

(maxv)

Sync with HEAD.  77 conflicts resolved - all of them $NetBSD$

(pgoyette)

support xmss keys

(christos)

fix unconst

(christos)

restore default xx salt.

(christos)

new ntp

(christos)

merge conflicts

(christos)

mention openssl

(christos)

merge conflicts

(christos)

in rtwn_attach(): return; before unconditionally running into fail:

(macallan)

- use c99 initializers
- add kdc offset functions

(christos)

don't forget to initialize the kdc_offset (it was random before)

(christos)

new openssh

(christos)

new openssh

(christos)

merge conflicts

(christos)

Change the iteration, to make sure the ACPI_MCFG_ALLOCATION structure we're
reading fits the table we allocated. Linux does the same.

I have a laptop which, for some reason, reports a table size of 62 bytes.
Clearly that's incorrect, it should be 60 (44 + 16). Because of the stray
+2, here the kernel reads past the end of the allocated buffer, hits an
unmapped VA, and panics at boot time. So the laptop can't boot.

Now it boots fine.

(maxv)

note to get rid of statfs() when bump time comes

(dholland)

Make GARP work again when DAD is disabled

The change avoids setting an IP address tentative on initializing it when the
IPv4 DAD is disabled (net.inet.ip.dad_count=0), which allows a GARP packet to be
sent (see arpannounce).  This is the same behavior of NetBSD 7, i.e., before
introducing the IPv4 DAD.

Additionally do the same change to IPv6 DAD for consistency.

The change is suggested by roy@

(ozaki-r)

Revert the previous two commits as per roy@'s request

It broke the ip_dad_count > 0 case unexpectedly.

(ozaki-r)

when CPPFLAGS include a parameter that has any spaces (e.g. CPPFLAGS="-DBN_LLONG=\"long long\""),
$CPP $CPPFLAGS fails. (aarch64--netbsd-clang: error: no such file or directory: 'long"')

advice to use "eval" by soda@. thanks.

(ryo)

If we're trying to read the mss on a packet that for some reason has two
MAXSEG options, we find ourselves patching the second option with the
value of the first one.

Fix that by using a local variable.

(maxv)

Note import of dhcpcd-7.0.3

(roy)

Sync

(roy)

Fix unexpected failure when ipsecif(4) over IPv6 is changed port number only.

Here is an example of the operation which causes this problem.
    # ifconfig ipsec0 create link0
    # ifconfig ipsec0 tunnel fc00:1001::2,4500 fc00:1001::1,4501
    # ifconfig ipsec0 tunnel fc00:1001::2,4500 fc00:1001::1,4502

(knakahara)

Add IPv4 ID when the ipsecif(4) packet can be fragmented. Implemented by hsuenaga@IIJ and ohishi@IIJ, thanks.

This modification reduces packet loss of fragmented packets on a
network where reordering occurs.

Alghough this modification has been applied, IPv4 ID is not set for
the packet smaller then IP_MINFRAGSIZE. According to RFC 6864, that
must not cause problems.

XXX pullup-8

(knakahara)

fix ipsecif(4) stack overflow.

XXX pullup-8

(knakahara)

fix ipsecif(4) unmatch curlwp_bind.

XXX pullup-8

(knakahara)

fix ipsec(4) encap_lock leak.

XXX pullup-8

(knakahara)

Add tests for GARP without DAD

Additionally make the existing tests for GARP more explicit.

(ozaki-r)

Show outputs of commands if $DEBUG

(ozaki-r)

Improve packet checks and error reporting

(ozaki-r)

Don't set IN_IFF_* flags to ia4_flags if DAD is disabled

This fix allows that a GARP packet is sent when adding an IP address to an
interface with IFF_UP on a kernel with IPv4 DAD is disabled
(net.inet.ip.dad_count=0), which is the same behavior of NetBSD 7, i.e.,
before introducing the IPv4 DAD.

(ozaki-r)

Simplify; clear then set flags to ia4_flags (NFCI)

(ozaki-r)

Fix bad cut'n'paste, pointed out by David Binderman in PR port-arm/53158

(bouyer)

switch m68000 and m68k to GCC 6.  ok mlelstv.

(mrg)

Pass -S to ed(1) so that patches containing ! commands don't run commands.
Real cause of CVS-2018-0492:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894667)

(christos)

add -S to disable ! commands.

(christos)

Ticket #696

(martin)

Pull up following revision(s) (requested by christos in ticket #696):

sys/arch/amd64/amd64/vector.S: revision 1.62 (patch)
sys/arch/x86/include/intr.h: revision 1.55
sys/arch/i386/i386/vector.S: revision 1.77
sys/arch/i386/i386/db_interface.c: revision 1.82 (patch)
sys/arch/amd64/amd64/spl.S: revision 1.34 (patch)
sys/arch/amd64/amd64/db_interface.c: revision 1.33 (patch)
sys/arch/x86/x86/intr.c: revision 1.125
sys/arch/i386/i386/spl.S: revision 1.43 (patch)
sys/arch/i386/i386/machdep.c: revision 1.805 (patch)
sys/arch/x86/x86/lapic.c: revision 1.66 (patch)

Rename the DDB IPI IDT vectors for consistency. ok maxv@

Rename Xpreempt{recurse,resume} -> X{recurse,resume}_preempt so that
they fit the pattern. Also the debugger trap sniffer matches them
without adding special entries...

XXX: pullup-8.

(martin)

Appease the compiler gods; yes I know what I am doing adding to a literal
string.

(christos)

Set the "method" string at boot time too.

(maxv)

Tickets #694, #695, and #697

(martin)

Pull up following revision(s) (requested by ozaki-r in ticket #697):

sys/net/route.c: revision 1.208

Kill remaining rt->rt_refcnt++

(martin)

Pull up following revision(s) (requested by maxv in ticket #695):

sys/kern/uipc_mbuf.c: revision 1.182
sys/netinet6/frag6.c: revision 1.67
sys/netinet/ip_reass.c: revision 1.14
sys/sys/mbuf.h: revision 1.179

Remove M_PKTHDR from secondary mbufs when reassembling packets.

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.

(martin)

Pull up following revision(s) (requested by maxv in ticket #694):

sys/netinet6/ip6_etherip.c: revision 1.22
sys/net/if_etherip.c: revision 1.41
sys/net/if_etherip.c: revision 1.42
sys/netinet/ip_etherip.c: revision 1.21

Don't call if_attach, do if_initialize+if_register, otherwise when an
EtherIP packet is received the first KASSERT in if_input() fires.

A few fixes:
* Style.
* Don't add M_PKTHDR manually, that's absolutely forbidden. Add a
  KASSERT to make sure it's already there.
* Add a missing NULL check after m_pullup.

(martin)

Hum, don't let userland set bit 13, because this can crash the kernel.

(maxv)

Fix the check, should be >=.

(maxv)

Ticket #1594

(martin)

Pull up following revision(s) (requested by maxv in ticket #1594):

sys/kern/uipc_mbuf.c: revision 1.182
sys/netinet6/frag6.c: revision 1.67
sys/netinet/ip_reass.c: revision 1.14
sys/sys/mbuf.h: revision 1.179

Remove M_PKTHDR from secondary mbufs when reassembling packets.

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.

(martin)

Ticket #1594

(martin)

Pull up following revision(s) (requested by maxv in ticket #1594):

sys/kern/uipc_mbuf.c: revision 1.182
sys/netinet6/frag6.c: revision 1.67
sys/netinet/ip_reass.c: revision 1.14
sys/sys/mbuf.h: revision 1.179

Remove M_PKTHDR from secondary mbufs when reassembling packets.

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.

(martin)

Ticket #1594

(martin)

Pull up following revision(s) (requested by maxv in ticket #1594):

sys/kern/uipc_mbuf.c: revision 1.182
sys/netinet6/frag6.c: revision 1.67
sys/netinet/ip_reass.c: revision 1.14
sys/sys/mbuf.h: revision 1.179

Remove M_PKTHDR from secondary mbufs when reassembling packets.

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.

(martin)

Ticket #1593

(martin)

Pullup the following revision, requested by maxv in ticket #1593:

sys/net/npf/npf.h 1.55

Fix a vulnerability in NPF, that allows whatever incoming IPv6 packet to
bypass a certain number of filtering rules.

Basically there is an integer overflow in npf_cache_ip: npc_hlen is a
8bit unsigned int, and can wrap to zero if the IPv6 packet being processed
has large extensions.

As a result of an overflow, (mbuf + npc_hlen) won't point at the real
protocol header, but instead at some garbage within the packet. That
garbage, is what NPF applies its rules on.

If these filtering rules allow the packet to enter, that packet is given
to the main IPv6 entry point. This entry point, however, is not subject to
an integer overflow, so it will actually parse the correct protocol header.

The result is: NPF read a wrong header, allowed the packet to enter, the
kernel read the correct header, and delivered the packet depending on this
correct header. So the offending packet was supposed to be kicked, but
still went through the firewall.

Simple example, a packet with:
        packet +  0 = IP6 Header
        packet +  40 = IP6 Routing header (ip6r_len = 31)
        packet +  48 = Crafted UDP header (uh_dport = 7777)
        packet + 296 = IP6 Dest header (ip6e_len = 0)
        packet + 304 = Real UDP header (uh_dport = 6666)
Will bypass a rule of the kind "block port 6666". Here NPF reads the
crafted UDP header, sees 7777, lets the packet in; later the kernel reads
the real UDP header, and delivers it on port 6666.

Fix this by using uint32_t. While here, it seems to me there is also a
memory overflow: still in npf_cache_ip, npc_hlen may be incremented with
a value that goes beyond the mbuf.

(martin)

Ticket #1593

(martin)

Pullup the following revision, requested by maxv in ticket #1593:

sys/net/npf/npf.h 1.55

Fix a vulnerability in NPF, that allows whatever incoming IPv6 packet to
bypass a certain number of filtering rules.

Basically there is an integer overflow in npf_cache_ip: npc_hlen is a
8bit unsigned int, and can wrap to zero if the IPv6 packet being processed
has large extensions.

As a result of an overflow, (mbuf + npc_hlen) won't point at the real
protocol header, but instead at some garbage within the packet. That
garbage, is what NPF applies its rules on.

If these filtering rules allow the packet to enter, that packet is given
to the main IPv6 entry point. This entry point, however, is not subject to
an integer overflow, so it will actually parse the correct protocol header.

The result is: NPF read a wrong header, allowed the packet to enter, the
kernel read the correct header, and delivered the packet depending on this
correct header. So the offending packet was supposed to be kicked, but
still went through the firewall.

Simple example, a packet with:
        packet +  0 = IP6 Header
        packet +  40 = IP6 Routing header (ip6r_len = 31)
        packet +  48 = Crafted UDP header (uh_dport = 7777)
        packet + 296 = IP6 Dest header (ip6e_len = 0)
        packet + 304 = Real UDP header (uh_dport = 6666)
Will bypass a rule of the kind "block port 6666". Here NPF reads the
crafted UDP header, sees 7777, lets the packet in; later the kernel reads
the real UDP header, and delivers it on port 6666.

Fix this by using uint32_t. While here, it seems to me there is also a
memory overflow: still in npf_cache_ip, npc_hlen may be incremented with
a value that goes beyond the mbuf.

(martin)

Ticket #1593

(martin)

Pullup the following revision, requested by maxv in ticket #1593:

sys/net/npf/npf.h 1.55

Fix a vulnerability in NPF, that allows whatever incoming IPv6 packet to
bypass a certain number of filtering rules.

Basically there is an integer overflow in npf_cache_ip: npc_hlen is a
8bit unsigned int, and can wrap to zero if the IPv6 packet being processed
has large extensions.

As a result of an overflow, (mbuf + npc_hlen) won't point at the real
protocol header, but instead at some garbage within the packet. That
garbage, is what NPF applies its rules on.

If these filtering rules allow the packet to enter, that packet is given
to the main IPv6 entry point. This entry point, however, is not subject to
an integer overflow, so it will actually parse the correct protocol header.

The result is: NPF read a wrong header, allowed the packet to enter, the
kernel read the correct header, and delivered the packet depending on this
correct header. So the offending packet was supposed to be kicked, but
still went through the firewall.

Simple example, a packet with:
        packet +  0 = IP6 Header
        packet +  40 = IP6 Routing header (ip6r_len = 31)
        packet +  48 = Crafted UDP header (uh_dport = 7777)
        packet + 296 = IP6 Dest header (ip6e_len = 0)
        packet + 304 = Real UDP header (uh_dport = 6666)
Will bypass a rule of the kind "block port 6666". Here NPF reads the
crafted UDP header, sees 7777, lets the packet in; later the kernel reads
the real UDP header, and delivers it on port 6666.

Fix this by using uint32_t. While here, it seems to me there is also a
memory overflow: still in npf_cache_ip, npc_hlen may be incremented with
a value that goes beyond the mbuf.

(martin)

Ticket #1542

(martin)

Pullup the following revision, requested by maxv in ticket #1542:

sys/net/npf/npf.h 1.55

Fix a vulnerability in NPF, that allows whatever incoming IPv6 packet to
bypass a certain number of filtering rules.

Basically there is an integer overflow in npf_cache_ip: npc_hlen is a
8bit unsigned int, and can wrap to zero if the IPv6 packet being processed
has large extensions.

As a result of an overflow, (mbuf + npc_hlen) won't point at the real
protocol header, but instead at some garbage within the packet. That
garbage, is what NPF applies its rules on.

If these filtering rules allow the packet to enter, that packet is given
to the main IPv6 entry point. This entry point, however, is not subject to
an integer overflow, so it will actually parse the correct protocol header.

The result is: NPF read a wrong header, allowed the packet to enter, the
kernel read the correct header, and delivered the packet depending on this
correct header. So the offending packet was supposed to be kicked, but
still went through the firewall.

Simple example, a packet with:
        packet +  0 = IP6 Header
        packet +  40 = IP6 Routing header (ip6r_len = 31)
        packet +  48 = Crafted UDP header (uh_dport = 7777)
        packet + 296 = IP6 Dest header (ip6e_len = 0)
        packet + 304 = Real UDP header (uh_dport = 6666)
Will bypass a rule of the kind "block port 6666". Here NPF reads the
crafted UDP header, sees 7777, lets the packet in; later the kernel reads
the real UDP header, and delivers it on port 6666.

Fix this by using uint32_t. While here, it seems to me there is also a
memory overflow: still in npf_cache_ip, npc_hlen may be incremented with
a value that goes beyond the mbuf.

(martin)

Ticket #1542

(martin)

Pullup the following revision, requested by maxv in ticket #1542:

sys/net/npf/npf.h 1.55

Fix a vulnerability in NPF, that allows whatever incoming IPv6 packet to
bypass a certain number of filtering rules.

Basically there is an integer overflow in npf_cache_ip: npc_hlen is a
8bit unsigned int, and can wrap to zero if the IPv6 packet being processed
has large extensions.

As a result of an overflow, (mbuf + npc_hlen) won't point at the real
protocol header, but instead at some garbage within the packet. That
garbage, is what NPF applies its rules on.

If these filtering rules allow the packet to enter, that packet is given
to the main IPv6 entry point. This entry point, however, is not subject to
an integer overflow, so it will actually parse the correct protocol header.

The result is: NPF read a wrong header, allowed the packet to enter, the
kernel read the correct header, and delivered the packet depending on this
correct header. So the offending packet was supposed to be kicked, but
still went through the firewall.

Simple example, a packet with:
        packet +  0 = IP6 Header
        packet +  40 = IP6 Routing header (ip6r_len = 31)
        packet +  48 = Crafted UDP header (uh_dport = 7777)
        packet + 296 = IP6 Dest header (ip6e_len = 0)
        packet + 304 = Real UDP header (uh_dport = 6666)
Will bypass a rule of the kind "block port 6666". Here NPF reads the
crafted UDP header, sees 7777, lets the packet in; later the kernel reads
the real UDP header, and delivers it on port 6666.

Fix this by using uint32_t. While here, it seems to me there is also a
memory overflow: still in npf_cache_ip, npc_hlen may be incremented with
a value that goes beyond the mbuf.

(martin)

Ticket #1542

(martin)

Pullup the following revision, requested by maxv in ticket #1542:

sys/net/npf/npf.h 1.55

Fix a vulnerability in NPF, that allows whatever incoming IPv6 packet to
bypass a certain number of filtering rules.

Basically there is an integer overflow in npf_cache_ip: npc_hlen is a
8bit unsigned int, and can wrap to zero if the IPv6 packet being processed
has large extensions.

As a result of an overflow, (mbuf + npc_hlen) won't point at the real
protocol header, but instead at some garbage within the packet. That
garbage, is what NPF applies its rules on.

If these filtering rules allow the packet to enter, that packet is given
to the main IPv6 entry point. This entry point, however, is not subject to
an integer overflow, so it will actually parse the correct protocol header.

The result is: NPF read a wrong header, allowed the packet to enter, the
kernel read the correct header, and delivered the packet depending on this
correct header. So the offending packet was supposed to be kicked, but
still went through the firewall.

Simple example, a packet with:
        packet +  0 = IP6 Header
        packet +  40 = IP6 Routing header (ip6r_len = 31)
        packet +  48 = Crafted UDP header (uh_dport = 7777)
        packet + 296 = IP6 Dest header (ip6e_len = 0)
        packet + 304 = Real UDP header (uh_dport = 6666)
Will bypass a rule of the kind "block port 6666". Here NPF reads the
crafted UDP header, sees 7777, lets the packet in; later the kernel reads
the real UDP header, and delivers it on port 6666.

Fix this by using uint32_t. While here, it seems to me there is also a
memory overflow: still in npf_cache_ip, npc_hlen may be incremented with
a value that goes beyond the mbuf.

(martin)

Use mdoc macros.

(wiz)

Remove AWIN_DEBE_FWINIT blocks

(jmcneill)

Remove NAWIN_MP blocks (this code was experimental in the original driver and is not worth porting over)

(jmcneill)

Call cpu_speculation_init on i386 too. We don't have IBRS for i386, but
we do have the AMD DIS_IND method.

(maxv)

pretty much everything depends upon insn-opinit.h via optabs-query.h
so set it in DPSRCS.  hopefully this fixes PR 53137.

(mrg)

Kill remaining rt->rt_refcnt++

(ozaki-r)

Be more selective about detecting a SYSV include as opposed to a dependency
line. Dependency lines should contain a '::' operator or ':<space>'.

(christos)

Add new ATF tests for Address Sanitzier (ASan)

Add new C and C++ tests:
- t_asan_double_free
- t_asan_global_buffer_overflow
- t_asan_heap_overflow
- t_asan_off_by_one
- t_asan_uaf

Each tests checks:
- regular build
- 32-bit
- PIC
- PIE
- profile

These tests require paxctl(8) to disable ASLR in order to work in a
predictable way. This is especially true for all !regular builds with
additional compiler flags.

There are no static variations of these tests as this mode is not supported
in upstream ASan.

Enable these tests on amd64 and i386.

This is part two patch, adding the remaining C++ changes.

Patch submitted by <Siddharth Muralee>
Additional polishing by myself.

(kamil)

Add new ATF tests for Address Sanitzier (ASan)

Add new C and C++ tests:
- t_asan_double_free
- t_asan_global_buffer_overflow
- t_asan_heap_overflow
- t_asan_off_by_one
- t_asan_uaf

Each tests checks:
- regular build
- 32-bit
- PIC
- PIE
- profile

These tests require paxctl(8) to disable ASLR in order to work in a
predictable way. This is especially true for all !regular builds with
additional compiler flags.

There are no static variations of these tests as this mode is not supported
in upstream ASan.

Enable these tests on amd64 and i386.

Patch submitted by <Siddharth Muralee>
Additional polishing by myself.

(kamil)

Rename Xpreempt{recurse,resume} -> X{recurse,resume}_preempt so that
they fit the pattern. Also the debugger trap sniffer matches them
without adding special entries...
XXX: pullup-8.

(christos)

Drop superfluous zero prefix for single digit number days.

heads up by wiz

(sevan)

Sort files in usr/tests/usr.bin/c++/

No functional change intended.

(kamil)