On Fri, Oct 06, 2023 at 12:06:13AM -0700, Maciej Żenczykowski wrote:
On Thu, Oct 5, 2023 at 11:21 PM Greg KH gregkh@linuxfoundation.org wrote:
On Fri, Oct 06, 2023 at 07:52:19AM +0200, Greg KH wrote:
On Thu, Oct 05, 2023 at 02:37:59PM -0700, Patrick Rohr wrote:
On Mon, Sep 25, 2023 at 2:10 PM Patrick Rohr prohr@google.com wrote:
This series adds a new sysctl accept_ra_min_lft which enforces a minimum lifetime value for individual RA sections; in particular, router lifetime, PIO preferred lifetime, and RIO lifetime. If any of those lifetimes are lower than the configured value, the specific RA section is ignored.
This fixes a potential denial of service attack vector where rogue WiFi routers (or devices) can send RAs with low lifetimes to actively drain a mobile device's battery (by preventing sleep).
In addition to this change, Android uses hardware offloads to drop RAs for a fraction of the minimum of all lifetimes present in the RA (some networks have very frequent RAs (5s) with high lifetimes (2h)). Despite this, we have encountered networks that set the router lifetime to 30s which results in very frequent CPU wakeups. Instead of disabling IPv6 (and dropping IPv6 ethertype in the WiFi firmware) entirely on such networks, misconfigured routers must be ignored while still processing RAs from other IPv6 routers on the same network (i.e. to support IoT applications).
Patches:
- 1671bcfd76fd ("net: add sysctl accept_ra_min_rtr_lft")
- 5027d54a9c30 ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes")
- 5cb249686e67 ("net: release reference to inet6_dev pointer")
Patrick Rohr (3): net: add sysctl accept_ra_min_rtr_lft net: change accept_ra_min_rtr_lft to affect all RA lifetimes net: release reference to inet6_dev pointer
Documentation/networking/ip-sysctl.rst | 8 ++++++++ include/linux/ipv6.h | 1 + include/uapi/linux/ipv6.h | 1 + net/ipv6/addrconf.c | 13 +++++++++++++ net/ipv6/ndisc.c | 13 +++++++++++-- 5 files changed, 34 insertions(+), 2 deletions(-)
-- 2.42.0.515.g380fc7ccd1-goog
Was this rejected? Any resolution on this (ACK or NAK) would be useful. Thanks!
They are in our "to get to" queue, which is very long still due to multiple conferences and travel.
But I will note, you didn't put the git id of the patches in the patches themselves, so it will take me extra work to add them there when applying.
Also, why just 6.1? What about newer stable kernels? You can't update and have a regression, right?
Note, because of this, we can not take these patches now at all anyway :(
thanks,
greg k-h
Because without any knowledge of whether these patches would even be accepted into stable, or whether they would need to go in via ACK, preparing them for more trees seemed like pointless busywork...
FWIW, the above just means that we get to do the busywork rather than the submitter...