summaryrefslogtreecommitdiff
path: root/drivers/net/wireguard/Makefile
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2022-07-29 19:23:22 +0200
committerJason A. Donenfeld <Jason@zx2c4.com>2022-07-30 02:47:02 +0200
commit27bfaeeb33af76977fd6b43a8cec9a8e75b5d4d1 (patch)
tree6c08b56ba54aaa4ca435cbb7cc825f6fae6c045f /drivers/net/wireguard/Makefile
parent5ebbf56434ddd15cddefe9b75232108a930cffa0 (diff)
downloadwireguard-linux-trimmed-jd/new-archs.tar.gz
wireguard-linux-trimmed-jd/new-archs.zip
wireguard: allowedips: don't corrupt stack when detecting overflowjd/new-archs
In case push_rcu() and related functions are buggy, there's a WARN_ON(len >= 128), which the selftest tries to hit by being tricky. In case it is hit, we shouldn't corrupt the kernel's stack, though; otherwise it may be hard to even receive the report that it's buggy. So conditionalize the stack write based on that WARN_ON()'s return value. Note that this never *actually* happens anyway. The WARN_ON() in the first place is bounded by IS_ENABLED(DEBUG), and isn't expected to ever actually hit. This is just a debugging sanity check. Additionally, hoist the constant 128 into a named enum, MAX_ALLOWEDIPS_BITS, so that it's clear why this value is chosen. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/all/CAHk-=wjJZGA6w_DxA+k7Ejbqsq+uGK==koPai3sqdsfJqemvag@mail.gmail.com/ Fixes: a8f1bc7bdea3 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Diffstat (limited to 'drivers/net/wireguard/Makefile')
0 files changed, 0 insertions, 0 deletions