1. 29 Oct, 2017 35 commits
  2. 28 Oct, 2017 5 commits
    • Pedro F. Giffuni's avatar
      bsnmpd: Only refresh devtree if devd event is a new or removed device. · 7e7315b5
      Pedro F. Giffuni authored
      It makes sense to refresh the tree only when a device is inserted or
      removed, otherwise bsnmpd wastes lot of CPU.
      PR:		209368
      MFC after:	1 week
    • Pedro F. Giffuni's avatar
      Fix out-of-bounds read in libc/regex. · 0f23ab8a
      Pedro F. Giffuni authored
      The bug is an out-of-bounds read detected with address sanitizer that
      happens when 'sp' in p_b_coll_elems() includes NUL byte[s], e.g. if it's
      equal to "GS\x00". In that case len will be equal to 4, and the
      strncmp(cp->name, sp, len) call will succeed when cp->name is "GS" but the
      cp->name[len] == '\0' comparison will cause the read to go out-of-bounds.
      Checking the length using strlen() instead eliminates the issue.
      The bug was found in LLVM with oss-fuzz:
      MFC after:	1 week
      Obtained from:	Vlad Tsyrklevich through posting on openbsd-tech
    • Ian Lepore's avatar
      Split the hardware type enum and the hw feature flags bits into separate · 3faac3ea
      Ian Lepore authored
      fields in the softc; they're ORed together in the ofw_compat_data.
      I already caught myself doing 'sc->fectype == <enum val>' without masking
      out the feature bits in one place, and that's sure to happen again.
      Glomming them together is convenient for storing them in the ofw_compat_data
      array, but there's no reason to keep them together in the softc.
    • Mariusz Zaborski's avatar
      Simplify ping sandbox. · 0b9d37d2
      Mariusz Zaborski authored
      We don't need to check if casper is present, this is done in the library itself.
      Reviewed by:	emaste, cem, ed
      Differential Revision:	https://reviews.freebsd.org/D8754
    • Ian Lepore's avatar
      Use the 16-bit receive shift feature in ffec hardware that supports it. · 9aba65fa
      Ian Lepore authored
      When available, enabling this feature causes the hardware to write data
      to the receive buffer starting at a 16-bit offset from the start address.
      This eliminates the need to copy the data after receiving to re-align
      the protocol headers to a 32-bit boundary.
      PR:		222634
      Submitted by:	sebastian.huber@embedded-brains.de