[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zd3WMs8-nw5SPTZE@nanopsycho>
Date: Tue, 27 Feb 2024 13:31:46 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Lin Ma <linma@....edu.cn>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, idosch@...dia.com, razor@...ckwall.org,
lucien.xin@...il.com, edwin.peer@...adcom.com, amcohen@...dia.com,
pctammela@...atatu.com, liuhangbin@...il.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS
writing back
Tue, Feb 27, 2024 at 01:11:28PM CET, linma@....edu.cn wrote:
>In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks
>IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic
>in the function `rtnl_bridge_setlink` to enable the loop to also check
>the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment
>removed the `break` statement and led to an error logic of the flags
>writing back at the end of this function.
>
>if (have_flags)
> memcpy(nla_data(attr), &flags, sizeof(flags));
> // attr should point to IFLA_BRIDGE_FLAGS NLA !!!
>
>Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS.
>However, this is not necessarily true fow now as the updated loop will let
>the attr point to the last NLA, even an invalid NLA which could cause
>overflow writes.
>
>This patch introduces a new variable `br_flag` to save the NLA pointer
>that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned
>error logic.
>
>Fixes: d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length")
>Signed-off-by: Lin Ma <linma@....edu.cn>
>---
>v1 -> v2: rename the br_flag to br_flags_attr which offers better
> description suggested by Nikolay.
https://www.kernel.org/doc/html/v6.6/process/maintainer-netdev.html?highlight=network#tl-dr
"don't repost your patches within one 24h period"
Powered by blists - more mailing lists