kernel/linux.git, branch v5.10.227

Linux 5.10.227

2024-10-17T13:08:39+00:00

Link: https://lore.kernel.org/r/20241015123916.821186887@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

net: dsa: microchip: fix build warning

2024-10-17T13:08:39+00:00

In commit 65a9383389db ("net: dsa: microchip: fix initial port flush problem"), the build warning of an unused variable showed up. Fix this by removing the variable entirely. Fixes: 65a9383389db ("net: dsa: microchip: fix initial port flush problem") Signed-off-by: Greg Kroah-Hartman

RDMA/hns: Fix uninitialized variable

2024-10-17T13:08:39+00:00

commit 2a38c0f10e6d7d28e06ff1eb1f350804c4850275 upstream. A random value will be returned if the condition below is not met, so it needs to be initialized. Fixes: 9ea9a53ea93b ("RDMA/hns: Add mapped page count checking for MTR") Link: https://lore.kernel.org/r/1624011020-16992-3-git-send-email-liweihang@huawei.com Signed-off-by: Yixing Liu Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman

ext4: fix warning in ext4_dio_write_end_io()

2024-10-17T13:08:39+00:00

commit 619f75dae2cf117b1d07f27b046b9ffb071c4685 upstream. The syzbot has reported that it can hit the warning in ext4_dio_write_end_io() because i_size < i_disksize. Indeed the reproducer creates a race between DIO IO completion and truncate expanding the file and thus ext4_dio_write_end_io() sees an inconsistent inode state where i_disksize is already updated but i_size is not updated yet. Since we are careful when setting up DIO write and consider it extending (and thus performing the IO synchronously with i_rwsem held exclusively) whenever it goes past either of i_size or i_disksize, we can use the same test during IO completion without risking entering ext4_handle_inode_extension() without i_rwsem held. This way we make it obvious both i_size and i_disksize are large enough when we report DIO completion without relying on unreliable WARN_ON. Reported-by: Fixes: 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") Signed-off-by: Jan Kara Reviewed-by: Ritesh Harjani (IBM) Link: https://lore.kernel.org/r/20231130095653.22679-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman

netfilter: ip6t_rpfilter: Fix regression with VRF interfaces

2024-10-17T13:08:38+00:00

commit efb056e5f1f0036179b2f92c1c15f5ea7a891d70 upstream. When calling ip6_route_lookup() for the packet arriving on the VRF interface, the result is always the real (slave) interface. Expect this when validating the result. Fixes: acc641ab95b66 ("netfilter: rpfilter/fib: Populate flowic_l3mdev field") Signed-off-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman

net: vrf: determine the dst using the original ifindex for multicast

2024-10-17T13:08:38+00:00

commit f2575c8f404911da83f25b688e12afcf4273e640 upstream. Multicast packets received on an interface bound to a VRF are marked as belonging to the VRF and the skb device is updated to point to the VRF device itself. This was fine even when a route was associated to a device as when performing a fib table lookup 'oif' in fib6_table_lookup (coming from 'skb->dev->ifindex' in ip6_route_input) was set to 0 when FLOWI_FLAG_SKIP_NH_OIF was set. With commit 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") this is not longer true and multicast traffic is not received on the original interface. Instead of adding back a similar check in fib6_table_lookup determine the dst using the original ifindex for multicast VRF traffic. To make things consistent across the function do the above for all strict packets, which was the logic before commit 6f12fa775530 ("vrf: mark skb for multicast or link-local as enslaved to VRF"). Note that reverting to this behavior should be fine as the change was about marking packets belonging to the VRF, not about their dst. Fixes: 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") Reported-by: Jianlin Shi Signed-off-by: Antoine Tenart Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20221220171825.1172237-1-atenart@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

net: seg6: fix seg6_lookup_any_nexthop() to handle VRFs using flowi_l3mdev

2024-10-17T13:08:38+00:00

commit a3bd2102e464202b58d57390a538d96f57ffc361 upstream. Commit 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") adds a new entry (flowi_l3mdev) in the common flow struct used for indicating the l3mdev index for later rule and table matching. The l3mdev_update_flow() has been adapted to properly set the flowi_l3mdev based on the flowi_oif/flowi_iif. In fact, when a valid flowi_iif is supplied to the l3mdev_update_flow(), this function can update the flowi_l3mdev entry only if it has not yet been set (i.e., the flowi_l3mdev entry is equal to 0). The SRv6 End.DT6 behavior in VRF mode leverages a VRF device in order to force the routing lookup into the associated routing table. This routing operation is performed by seg6_lookup_any_nextop() preparing a flowi6 data structure used by ip6_route_input_lookup() which, in turn, (indirectly) invokes l3mdev_update_flow(). However, seg6_lookup_any_nexthop() does not initialize the new flowi_l3mdev entry which is filled with random garbage data. This prevents l3mdev_update_flow() from properly updating the flowi_l3mdev with the VRF index, and thus SRv6 End.DT6 (VRF mode)/DT46 behaviors are broken. This patch correctly initializes the flowi6 instance allocated and used by seg6_lookup_any_nexhtop(). Specifically, the entire flowi6 instance is wiped out: in case new entries are added to flowi/flowi6 (as happened with the flowi_l3mdev entry), we should no longer have incorrectly initialized values. As a result of this operation, the value of flowi_l3mdev is also set to 0. The proposed fix can be tested easily. Starting from the commit referenced in the Fixes, selftests [1],[2] indicate that the SRv6 End.DT6 (VRF mode)/DT46 behaviors no longer work correctly. By applying this patch, those behaviors are back to work properly again. [1] - tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh [2] - tools/testing/selftests/net/srv6_end_dt6_l3vpn_test.sh Fixes: 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") Reported-by: Anton Makarov Signed-off-by: Andrea Mayer Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20220608091917.20345-1-andrea.mayer@uniroma2.it Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

net: Handle l3mdev in ip_tunnel_init_flow

2024-10-17T13:08:38+00:00

commit db53cd3d88dc328dea2e968c9c8d3b4294a8a674 upstream. Ido reported that the commit referenced in the Fixes tag broke a gre use case with dummy devices. Add a check to ip_tunnel_init_flow to see if the oif is an l3mdev port and if so set the oif to 0 to avoid the oif comparison in fib_lookup_good_nhc. Fixes: 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") Reported-by: Ido Schimmel Signed-off-by: David Ahern Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

xfrm: Pass flowi_oif or l3mdev as oif to xfrm_dst_lookup

2024-10-17T13:08:38+00:00

commit 748b82c23e25310fec54e1eff2cb63936f391b24 upstream. The commit referenced in the Fixes tag no longer changes the flow oif to the l3mdev ifindex. A xfrm use case was expecting the flowi_oif to be the VRF if relevant and the change broke that test. Update xfrm_bundle_create to pass oif if set and any potential flowi_l3mdev if oif is not set. Fixes: 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") Reported-by: kernel test robot Signed-off-by: David Ahern Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman

net: geneve: add missing netlink policy and size for IFLA_GENEVE_INNER_PROTO_INHERIT

2024-10-17T13:08:38+00:00

commit 36c2e31ad25bd087756b8db9584994d1d80c236b upstream. Add missing netlink attribute policy and size calculation. Also enable strict validation from this new attribute onwards. Fixes: 435fe1c0c1f7 ("net: geneve: support IPv4/IPv6 as inner protocol") Signed-off-by: Eyal Birger Link: https://lore.kernel.org/r/20220322043954.3042468-1-eyal.birger@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman