Re: [PATCH net v3 1/1] net: l3mdev: Reject non-L3 uppers in slave helpers

[Yuan Tan <yuantan098@gmail.com>]

On 4/21/2026 2:10 AM, Ido Schimmel wrote:
> On Mon, Apr 20, 2026 at 09:26:50PM +0300, Ido Schimmel wrote:
>> On Mon, Apr 20, 2026 at 02:32:08PM +0300, Ido Schimmel wrote:
>>> On Sun, Apr 19, 2026 at 10:53:32PM +0800, Ren Wei wrote:
>>>> From: Haoze Xie <royenheart@gmail.com>
>>>>
>>>> Several l3mdev slave-side helpers resolve an upper device and then use
>>>> l3mdev_ops without first proving that the resolved device is still a
>>>> valid L3 master.
>>>>
>>>> During slave transition, an RCU reader can transiently observe an upper
>>>> that is not an L3 master. Guard the affected slave-resolved paths by
>>>> requiring the resolved upper to still be an L3 master before using
>>>> l3mdev_ops, while keeping existing L3 RX handler providers intact.
>>>>
>>>> Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking")
>>>> Cc: stable@kernel.org
>>>> Reported-by: Yifan Wu <yifanwucs@gmail.com>
>>>> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
>>>> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
>>>> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
>>>> Suggested-by: Xin Liu <bird@lzu.edu.cn>
>>>> Tested-by: Haoze Xie <royenheart@gmail.com>
>>>> Signed-off-by: Haoze Xie <royenheart@gmail.com>
>>>> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
>>> I think it's fine for net:
>>>
>>> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
>> Thought about this again. I would like to check another approach
>> (synchronize_net() after clearing IFF_L3MDEV_SLAVE). Will update
>> tomorrow.
> Sorry about the back and forth, but I thought about it again last night
> and I think that this is a better fix:
>
> https://github.com/idosch/linux/commit/e67517758ebcddf8a1b97817e4ab0fbf82f467fe.patch
>
> It's a minimal fix in the control plane of the VRF driver which doesn't
> add more checks in the data path. I can submit it later this week unless
> there are objections.

Thank for you time and review!

Btw could you add a Reported-by: Yuan Tan <yuantan098@gmail.com>? Thanks.