net: add sysctl accept_ra_min_lft

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

Quoted 38 lines · Patrick Rohr

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(-)

Quoted 3 lines

--
2.42.0.515.g380fc7ccd1-goog

Was this rejected?
Any resolution on this (ACK or NAK) would be useful. Thanks!

Quoted 39 lines · Patrick Rohr

Quoted 38 lines · Patrick Rohr

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(-)

Quoted 6 lines

Quoted 3 lines

--
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?

Quoted 54 lines · Greg KH

Quoted 39 lines · Patrick Rohr

Quoted 38 lines · Patrick Rohr

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(-)

Quoted 6 lines

Quoted 3 lines

--
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.

Quoted 2 lines

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

Quoted 61 lines · Greg KH

Quoted 50 lines · Greg KH

Quoted 39 lines · Patrick Rohr

Quoted 38 lines · Patrick Rohr

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(-)

Quoted 6 lines

Quoted 3 lines

--
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.

Quoted 6 lines

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 :(

Quoted 3 lines

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...

Quoted 61 lines · Greg KH

Quoted 50 lines · Greg KH

Quoted 39 lines · Patrick Rohr

Quoted 38 lines · Patrick Rohr

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(-)

Quoted 6 lines

Quoted 3 lines

--
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.

Quoted 6 lines

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 :(

Quoted 3 lines

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...

Quoted 13 lines

Quoted 13 lines

Quoted 12 lines

Quoted 2 lines

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?

Quoted 5 lines

Quoted 1 line

Note, because of this, we can not take these patches now at all anyway :(

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...

Quoted 13 lines

Quoted 13 lines

Quoted 13 lines

Quoted 12 lines

Quoted 2 lines

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?

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Note, because of this, we can not take these patches now at all anyway :(

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...

We're certainly willing to do the work, but we're not entirely sure what you want,
and whether you will indeed even accept these patches... We're just trying to be mindful of everyone's time...

For example as a reviewer myself I know that in many cases it is simply easier to do the
clean (!) cherrypick yourself (you presumably have scripts that automate the entire thing),
rather than try to verify that someone else's cherrypick is actually indeed clean.

These patches cleanly cherry pick, build, and pass our tests on current 6.5 and 6.1 LTS.

git checkout remotes/linux-stable/v6.5.6 && git cherry-pick 1671bcfd76fdc0b9e65153cf759153083755fe4c && git cherry-pick 5027d54a9c30bc7ec808360378e2b4753f053f25 && git cherry-pick 5cb249686e67dbef3ffe53887fa725eefc5a7144 && run_uml_ack_net_test

(and same thing with 6.1.56)

Do you simply want the upstream sha1s?

Or do you want us to follow up with patches?

Quoted 42 lines · Maciej Żenczykowski

Quoted 13 lines

Quoted 13 lines

Quoted 13 lines

Quoted 12 lines

Quoted 2 lines

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?

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Note, because of this, we can not take these patches now at all anyway :(

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...

We're certainly willing to do the work, but we're not entirely sure what you want,
and whether you will indeed even accept these patches... We're just trying to be mindful of everyone's time...

For example as a reviewer myself I know that in many cases it is simply easier to do the
clean (!) cherrypick yourself (you presumably have scripts that automate the entire thing),
rather than try to verify that someone else's cherrypick is actually indeed clean.

These patches cleanly cherry pick, build, and pass our tests on current 6.5 and 6.1 LTS.

git checkout remotes/linux-stable/v6.5.6 && git cherry-pick 1671bcfd76fdc0b9e65153cf759153083755fe4c && git cherry-pick 5027d54a9c30bc7ec808360378e2b4753f053f25 && git cherry-pick 5cb249686e67dbef3ffe53887fa725eefc5a7144 && run_uml_ack_net_test

Quoted 3 lines

(and same thing with 6.1.56)

Do you simply want the upstream sha1s?

For things that cherry-pick cleanly, yes, that's easiest.