1. 29 Jan, 2019 2 commits
  2. 28 Jan, 2019 1 commit
  3. 25 Jan, 2019 5 commits
  4. 23 Jan, 2019 3 commits
    • Gustavo A. R. Silva's avatar
      Bluetooth: Mark expected switch fall-throughs · 6317950c
      Gustavo A. R. Silva authored
      In preparation to enabling -Wimplicit-fallthrough, mark switch cases
      where we are expecting to fall through.
      
      This patch fixes the following warnings:
      
      net/bluetooth/rfcomm/core.c:479:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
      net/bluetooth/l2cap_core.c:4223:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
      
      Warning level 3 was used: -Wimplicit-fallthrough=3
      
      This patch is part of the ongoing efforts to enabling
      -Wimplicit-fallthrough.
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      6317950c
    • Marcel Holtmann's avatar
      Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer · 7c9cbd0b
      Marcel Holtmann authored
      The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt->len
      as length value. The opt->len however is in control over the remote user
      and can be used by an attacker to gain access beyond the bounds of the
      actual packet.
      
      To prevent any potential leak of heap memory, it is enough to check that
      the resulting len calculation after calling l2cap_get_conf_opt is not
      below zero. A well formed packet will always return >= 0 here and will
      end with the length value being zero after the last option has been
      parsed. In case of malformed packets messing with the opt->len field the
      length value will become negative. If that is the case, then just abort
      and ignore the option.
      
      In case an attacker uses a too short opt->len value, then garbage will
      be parsed, but that is protected by the unknown option handling and also
      the option parameter size checks.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      7c9cbd0b
    • Marcel Holtmann's avatar
      Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt · af3d5d1c
      Marcel Holtmann authored
      When doing option parsing for standard type values of 1, 2 or 4 octets,
      the value is converted directly into a variable instead of a pointer. To
      avoid being tricked into being a pointer, check that for these option
      types that sizes actually match. In L2CAP every option is fixed size and
      thus it is prudent anyway to ensure that the remote side sends us the
      right option size along with option paramters.
      
      If the option size is not matching the option type, then that option is
      silently ignored. It is a protocol violation and instead of trying to
      give the remote attacker any further hints just pretend that option is
      not present and proceed with the default values. Implementation
      following the specification and its qualification procedures will always
      use the correct size and thus not being impacted here.
      
      To keep the code readable and consistent accross all options, a few
      cosmetic changes were also required.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      af3d5d1c
  5. 22 Jan, 2019 9 commits
  6. 21 Jan, 2019 4 commits
  7. 20 Jan, 2019 16 commits