It looks like this is just a kernel memory leak? I suppose it could lead to DoS attacks from untrusted containers, but that seems to be the extent of it.
Also, the issue seems to be with storing already-parsed IPv6 addresses, not with actually parsing them.
> The device stores IPv6 addresses that are used for encapsulation in
linear memory that is managed by the driver.
> Changing the remote address of an ip6gre net device never worked
properly, but since cited commit the following reproducer [1] would
result in a warning [2] and a memory leak [3]. The problem is that the
new remote address is never added by the driver to its hash table (and
therefore the device) and the old address is never removed from it.
I wasn't familiar with the 'mlxsw' module so I found this on GitHub which was quite helpful: https://github.com/Mellanox/mlxsw/wiki. Seems the impact is even more niche (i.e. this won't be affecting most people's cloud VMs and regular linux desktop/mobile users):
> mlxsw: Mellanox Technologies is the first hardware vendor to use the switchdev API to offload the kernel's forwarding plane to a real ASIC. Mellanox's/Nvidia's current switchdev-based solution is focused on Spectrum ASICs.
I still don't see any reason why I shouldn't disable ipv6 everywhere I can. I lose nothing by doing so and gain only potential trouble by allowing it to be enabled.
It looks like this is just a kernel memory leak? I suppose it could lead to DoS attacks from untrusted containers, but that seems to be the extent of it.
Also, the issue seems to be with storing already-parsed IPv6 addresses, not with actually parsing them.
It seems to be about a GRE tunnel implementation too:
From https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
> The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver.
> Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it.
I wasn't familiar with the 'mlxsw' module so I found this on GitHub which was quite helpful: https://github.com/Mellanox/mlxsw/wiki. Seems the impact is even more niche (i.e. this won't be affecting most people's cloud VMs and regular linux desktop/mobile users):
> mlxsw: Mellanox Technologies is the first hardware vendor to use the switchdev API to offload the kernel's forwarding plane to a real ASIC. Mellanox's/Nvidia's current switchdev-based solution is focused on Spectrum ASICs.
This vulnerability CVE-2024-50252 is about IPv6 parsing in linux
Edit: Not about nvidia drivers like OP posted, but has since edited.
All patches linked in the CVE refer to a Mellanox (these days owned by Nvidia) network card driver, in combination with IPv4 over IPv6 GRE.
I don't think that's a very common configuration but from what I can tell it does only affect Linux hosts connected to Mellanox/Nvidia network cards.
[flagged]
I still don't see any reason why I shouldn't disable ipv6 everywhere I can. I lose nothing by doing so and gain only potential trouble by allowing it to be enabled.