linux-kernel - Re: [PATCHv2 net 1/2] bonding: fix incorrect MAC address setting to receive NS messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <624905.1738891174@famine>
Date: Thu, 06 Feb 2025 17:19:34 -0800
From: Jay Vosburgh <jv@...sburgh.net>
To: Hangbin Liu <liuhangbin@...il.com>
cc: netdev@...r.kernel.org, Andrew Lunn <andrew+netdev@...n.ch>,
    "David S. Miller" <davem@...emloft.net>,
    Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
    Paolo Abeni <pabeni@...hat.com>,
    Nikolay Aleksandrov <razor@...ckwall.org>,
    Simon Horman <horms@...nel.org>, Jianbo Liu <jianbol@...dia.com>,
    Boris Pismenny <borisp@...dia.com>, Tariq Toukan <tariqt@...dia.com>,
    Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
    linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2 net 1/2] bonding: fix incorrect MAC address setting to
 receive NS messages

Hangbin Liu <liuhangbin@...il.com> wrote:

>When validation on the backup slave is enabled, we need to validate the
>Neighbor Solicitation (NS) messages received on the backup slave. To
>receive these messages, the correct destination MAC address must be added
>to the slave. However, the target in bonding is a unicast address, which
>we cannot use directly. Instead, we should first convert it to a
>Solicited-Node Multicast Address and then derive the corresponding MAC
>address.
>
>Fixes: 8eb36164d1a6 ("bonding: add ns target multicast address to slave device")
>Signed-off-by: Hangbin Liu <liuhangbin@...il.com>

	I think this now deserves some commentary in the code.  Not
because this function itself is unclear, but because there's the
similarly-named slave_set_ns_maddr() (singular, not plural as in this
patch) that will behave in a subtly different manner after this patch is
applied.

	The "maddrs" version here will convert the provided IPv6 address
to the IPv6 solicited-nodes multicast address (RFC 4291 section 2.7.1)
and thence to the MAC address, via ndisc_mc_map(), whereas the "maddr"
version uses the supplied IPv6 address directly for multicast MAC
address conversion.

	Assuming that I'm following that correctly, I think this
distinction deserves explanation.  And if I'm getting it wrong, then it
definitely deserves some explanation.

	FWIW, functionally, I think it's doing the correct thing.

	-J

>---
> drivers/net/bonding/bond_options.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
>index 327b6ecdc77e..63cf209dcdc9 100644
>--- a/drivers/net/bonding/bond_options.c
>+++ b/drivers/net/bonding/bond_options.c
>@@ -1246,6 +1246,7 @@ static void slave_set_ns_maddrs(struct bonding *bond, struct slave *slave, bool
> {
> 	struct in6_addr *targets = bond->params.ns_targets;
> 	char slot_maddr[MAX_ADDR_LEN];
>+	struct in6_addr mcaddr;
> 	int i;
> 
> 	if (!slave_can_set_ns_maddr(bond, slave))
>@@ -1255,7 +1256,8 @@ static void slave_set_ns_maddrs(struct bonding *bond, struct slave *slave, bool
> 		if (ipv6_addr_any(&targets[i]))
> 			break;
> 
>-		if (!ndisc_mc_map(&targets[i], slot_maddr, slave->dev, 0)) {
>+		addrconf_addr_solict_mult(&targets[i], &mcaddr);
>+		if (!ndisc_mc_map(&mcaddr, slot_maddr, slave->dev, 0)) {
> 			if (add)
> 				dev_mc_add(slave->dev, slot_maddr);
> 			else
>-- 
>2.46.0
>

---
	-Jay Vosburgh, jv@...sburgh.net