Skip to content
  • Daniel Micay's avatar
    include/linux/string.h: add the option of fortified string.h functions · 6974f0c4
    Daniel Micay authored
    This adds support for compiling with a rough equivalent to the glibc
    _FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer
    overflow checks for string.h functions when the compiler determines the
    size of the source or destination buffer at compile-time.  Unlike glibc,
    it covers buffer reads in addition to writes.
    GNU C __builtin_*_chk intrinsics are avoided because they would force a
    much more complex implementation.  They aren't designed to detect read
    overflows and offer no real benefit when using an implementation based
    on inline checks.  Inline checks don't add up to much code size and
    allow full use of the regular string intrinsics while avoiding the need
    for a bunch of _chk functions and per-arch assembly to avoid wrapper
    This detects various overflows at compile-time in various drivers and
    some non-x86 core kernel code.  There will likely be issues caught in
    regular use at runtime too.
    Future improvements left out of initial implementation for simplicity,
    as it's all quite optional and can be done incrementally:
    * Some of the fortified string functions (strncpy, strcat), don't yet
      place a limit on reads from the source based on __builtin_object_size of
      the source buffer.
    * Extending coverage to more string functions like strlcat.
    * It should be possible to optionally use __builtin_object_size(x, 1) for
      some functions (C strings) to detect intra-object overflows (like
      glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative
      approach to avoid likely compatibility issues.
    * The compile-time checks should be made available via a separate config
      option which can be enabled by default (or always enabled) once enough
      time has passed to get the issues it catches fixed.
    Kees said:
     "This is great to have. While it was out-of-tree code, it would have
      blocked at least CVE-2016-3858 from being exploitable (improper size
      argument to strlcpy()). I've sent a number of fixes for
      out-of-bounds-reads that this detected upstream already"
    [ x86: fix fortified memcpy]
    [ avoid panic() in favor of BUG()]
    [ move from -mm, add ARCH_HAS_FORTIFY_SOURCE, tweak Kconfig help]
    Signed-off-by: default avatarDaniel Micay <>
    Signed-off-by: default avatarKees Cook <>
    Signed-off-by: default avatarArnd Bergmann <>
    Acked-by: default avatarKees Cook <>
    Cc: Mark Rutland <>
    Cc: Daniel Axtens <>
    Cc: Rasmus Villemoes <>
    Cc: Andy Shevchenko <>
    Cc: Chris Metcalf <>
    Cc: Thomas Gleixner <>
    Cc: "H. Peter Anvin" <>
    Cc: Ingo Molnar <>
    Signed-off-by: default avatarAndrew Morton <>
    Signed-off-by: default avatarLinus Torvalds <>