From: Jian Shen <shenjian15@huawei.com>

Currently, the VLAN id may be used without validation when
receive a VLAN configuration mailbox from VF. It may cause
out-of-bounds memory access once the VLAN id is bigger than
4095.

Fixes: fe4144d47eef ("net: hns3: sync VLAN filter entries when kill VLAN ID failed")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Jijie Shao <shaojijie@huawei.com>
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index cf8abbe01840..c589baea7c77 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -10555,6 +10555,9 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle, __be16 proto,
 	bool writen_to_tbl = false;
 	int ret = 0;
 
+	if (vlan_id >= VLAN_N_VID)
+		return -EINVAL;
+
 	/* When device is resetting or reset failed, firmware is unable to
 	 * handle mailbox. Just record the vlan id, and remove it after
 	 * reset finished.
-- 
2.33.0

On Tue, Dec 09, 2025 at 09:38:25PM +0800, Jijie Shao wrote:
> From: Jian Shen <shenjian15@huawei.com>
> 
> Currently, the VLAN id may be used without validation when
> receive a VLAN configuration mailbox from VF. It may cause
> out-of-bounds memory access once the VLAN id is bigger than
> 4095.
> 
> Fixes: fe4144d47eef ("net: hns3: sync VLAN filter entries when kill VLAN ID failed")
> Signed-off-by: Jian Shen <shenjian15@huawei.com>
> Signed-off-by: Jijie Shao <shaojijie@huawei.com>

Hi Jijie,

Can you clarify that the (only) oob access is to vlan_del_fail_bmap?

If so, I agree with this change and that the problem was introduced in
the cited commit. But I think it would be worth mentioning vlan_del_fail_bmap
in the commit message.


...

on 2025/12/10 0:50, Simon Horman wrote:
> On Tue, Dec 09, 2025 at 09:38:25PM +0800, Jijie Shao wrote:
>> From: Jian Shen <shenjian15@huawei.com>
>>
>> Currently, the VLAN id may be used without validation when
>> receive a VLAN configuration mailbox from VF. It may cause
>> out-of-bounds memory access once the VLAN id is bigger than
>> 4095.
>>
>> Fixes: fe4144d47eef ("net: hns3: sync VLAN filter entries when kill VLAN ID failed")
>> Signed-off-by: Jian Shen <shenjian15@huawei.com>
>> Signed-off-by: Jijie Shao <shaojijie@huawei.com>
> Hi Jijie,
>
> Can you clarify that the (only) oob access is to vlan_del_fail_bmap?
>
> If so, I agree with this change and that the problem was introduced in
> the cited commit. But I think it would be worth mentioning vlan_del_fail_bmap
> in the commit message.
>
Yes, the length of vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID).
Therefore, vlan_id needs to be checked to ensure it is within the range of VLAN_N_VID.

I will add this in V2

Thanks,
Jijie Shao


> ...
>

On Wed, Dec 10, 2025 at 02:39:11PM +0800, Jijie Shao wrote:
> 
> on 2025/12/10 0:50, Simon Horman wrote:
> > On Tue, Dec 09, 2025 at 09:38:25PM +0800, Jijie Shao wrote:
> > > From: Jian Shen <shenjian15@huawei.com>
> > > 
> > > Currently, the VLAN id may be used without validation when
> > > receive a VLAN configuration mailbox from VF. It may cause
> > > out-of-bounds memory access once the VLAN id is bigger than
> > > 4095.
> > > 
> > > Fixes: fe4144d47eef ("net: hns3: sync VLAN filter entries when kill VLAN ID failed")
> > > Signed-off-by: Jian Shen <shenjian15@huawei.com>
> > > Signed-off-by: Jijie Shao <shaojijie@huawei.com>
> > Hi Jijie,
> > 
> > Can you clarify that the (only) oob access is to vlan_del_fail_bmap?
> > 
> > If so, I agree with this change and that the problem was introduced in
> > the cited commit. But I think it would be worth mentioning vlan_del_fail_bmap
> > in the commit message.
> > 
> Yes, the length of vlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID).
> Therefore, vlan_id needs to be checked to ensure it is within the range of VLAN_N_VID.
> 
> I will add this in V2

Thanks.

Feel free to also add:

Reviewed-by: Simon Horman <horms@kernel.org>