From nobody Fri Apr 3 08:34:56 2026 Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DDBE3FD121 for ; Tue, 24 Mar 2026 14:35:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.188 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774362931; cv=none; b=mMZAiOd20QtU8pipzS/bCT+rMc6mgLFp66/L7QKXPZojsIDefMTs07uQwYLWUxts5J0l1X7BzN3MyBZCV0WTn9TyKZtym48sPJdlOL6IBfO/tdbSUnP1dkFPWSIN6cyRrSG6157x78XMKv+zT9cYPyuXyeNz+HVWB2buNASoziA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774362931; c=relaxed/simple; bh=4hrUhnoaKveSU+PDlzp55IOc5xwLAeYrWhRrD4mc9Kg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CSBZ5Zb2WFwUueUUWfqWfh/eaxlV5BJno24KmB+Pc6fB4bX48g76mBqd1D6pN2jxM7k0v/UcPSYZWPfPzAsHBNCkcDxzcGprLoyjY9CQPCfe0HXy9pp8AWZcV7SIFlnNLDnrlZU0yPeNliRW3ieoRRj9f8WC6pIgMlUmV7fSRcY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=XGeJChWS; arc=none smtp.client-ip=91.218.175.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="XGeJChWS" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774362928; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KJnFrFlNIpZDRT68oQPN1Mvm05ZQfMpajX/85miZxDA=; b=XGeJChWSqL/bVm4CCPHTnh50ovC+FAdBC5S3MiZFOQl8wCyABtdpBGAughPVJj0/cCYy8E 6ej8cBUadT/xQwiEom0h9lohQQj8nZObeh/asBxM32Wv325G0dW6bLLYSW3Olpr+y5YFar /uVe53YBiJpkdQAMDCiCaG0LwDNX4dE= From: luka.gejak@linux.dev To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org Cc: horms@kernel.org, fmaurer@redhat.com, liuhangbin@gmail.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, Luka Gejak Subject: [PATCH net-next v1 1/4] net: hsr: serialize seq_blocks merge across nodes Date: Tue, 24 Mar 2026 15:35:00 +0100 Message-ID: <20260324143503.187642-2-luka.gejak@linux.dev> In-Reply-To: <20260324143503.187642-1-luka.gejak@linux.dev> References: <20260324143503.187642-1-luka.gejak@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" From: Luka Gejak During node merging, hsr_handle_sup_frame() walks node_curr->seq_blocks to update node_real without holding node_curr->seq_out_lock. This allows concurrent mutations from duplicate registration paths, risking inconsistent state or XArray/bitmap corruption. Fix this by locking both nodes' seq_out_lock during the merge. To prevent ABBA deadlocks, locks are acquired in order of memory address. Signed-off-by: Luka Gejak Reviewed-by: Felix Maurer --- net/hsr/hsr_framereg.c | 38 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/net/hsr/hsr_framereg.c b/net/hsr/hsr_framereg.c index 577fb588bc2f..d09875b33588 100644 --- a/net/hsr/hsr_framereg.c +++ b/net/hsr/hsr_framereg.c @@ -123,6 +123,40 @@ static void hsr_free_node_rcu(struct rcu_head *rn) hsr_free_node(node); } =20 +static void hsr_lock_seq_out_pair(struct hsr_node *node_a, + struct hsr_node *node_b) +{ + if (node_a =3D=3D node_b) { + spin_lock_bh(&node_a->seq_out_lock); + return; + } + + if (node_a < node_b) { + spin_lock_bh(&node_a->seq_out_lock); + spin_lock_nested(&node_b->seq_out_lock, SINGLE_DEPTH_NESTING); + } else { + spin_lock_bh(&node_b->seq_out_lock); + spin_lock_nested(&node_a->seq_out_lock, SINGLE_DEPTH_NESTING); + } +} + +static void hsr_unlock_seq_out_pair(struct hsr_node *node_a, + struct hsr_node *node_b) +{ + if (node_a =3D=3D node_b) { + spin_unlock_bh(&node_a->seq_out_lock); + return; + } + + if (node_a < node_b) { + spin_unlock(&node_b->seq_out_lock); + spin_unlock_bh(&node_a->seq_out_lock); + } else { + spin_unlock(&node_a->seq_out_lock); + spin_unlock_bh(&node_b->seq_out_lock); + } +} + void hsr_del_nodes(struct list_head *node_db) { struct hsr_node *node; @@ -432,7 +466,7 @@ void hsr_handle_sup_frame(struct hsr_frame_info *frame) } =20 ether_addr_copy(node_real->macaddress_B, ethhdr->h_source); - spin_lock_bh(&node_real->seq_out_lock); + hsr_lock_seq_out_pair(node_real, node_curr); for (i =3D 0; i < HSR_PT_PORTS; i++) { if (!node_curr->time_in_stale[i] && time_after(node_curr->time_in[i], node_real->time_in[i])) { @@ -455,7 +489,7 @@ void hsr_handle_sup_frame(struct hsr_frame_info *frame) src_blk->seq_nrs[i], HSR_SEQ_BLOCK_SIZE); } } - spin_unlock_bh(&node_real->seq_out_lock); + hsr_unlock_seq_out_pair(node_real, node_curr); node_real->addr_B_port =3D port_rcv->type; =20 spin_lock_bh(&hsr->list_lock); --=20 2.53.0 From nobody Fri Apr 3 08:34:56 2026 Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BBF13FE357 for ; Tue, 24 Mar 2026 14:35:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774362932; cv=none; b=VJQTRBOmVmPP94lZtVQZ1Pe69KDBsQlsA/MP3m9N92fvH4zJ2n5T3zwCaNHt5XWzw+Tj8ogijfWGABv4nFZNlXQFcNnkY97w297sV39GP0wxkfW20oEOI63uO2uUELkHo9pz0kIVtvRnCzKqJsO9qzkqG/lswGJOLgcB3tfDfdQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774362932; c=relaxed/simple; bh=/jljxnOLNg2AHRSw8dBEkP5R54o65pi8/FGgJD0ZF2o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cd8Xv3RPnakUN4aendtyTOdkSxnY80Z1hG37vYJ/VnXAuzLMoHyuhWJGASevzBCShkXFF0Wd2IFpcDE1fwbsIERlTP31lzQ0IiSsrJAEWGRZdrGX8jMcEtV5QUTBaajEfTCxnJFMs+hc92ThnAK2zyzft5OwRkmjG/AwKuhgrsY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=CDEpGlWZ; arc=none smtp.client-ip=91.218.175.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="CDEpGlWZ" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774362929; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JsfdeQJgNjPfFiX1IeXG3ukvlqw4gMRgg97K1ZPW8yY=; b=CDEpGlWZ0m4kyF1QSKgZ8n1jRa5ZTq07EozDUTxEXw/mfly5OOyd7Y35bXCiwI/ejQvL6d adZC9V3kY/SQb91IGfH8o6NS94067/RXutS1dTVKURhgzuOy4xlDVibuutT97zM3mVIkn0 g+6SDLMqfCS1Pf31kx9De30UGzSBGjo= From: luka.gejak@linux.dev To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org Cc: horms@kernel.org, fmaurer@redhat.com, liuhangbin@gmail.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, Luka Gejak Subject: [PATCH net-next v1 2/4] net: hsr: fix VLAN add unwind on slave errors Date: Tue, 24 Mar 2026 15:35:01 +0100 Message-ID: <20260324143503.187642-3-luka.gejak@linux.dev> In-Reply-To: <20260324143503.187642-1-luka.gejak@linux.dev> References: <20260324143503.187642-1-luka.gejak@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" From: Luka Gejak When vlan_vid_add() fails for a secondary slave, the error path calls vlan_vid_del() on the failing port instead of the peer slave that had already succeeded. This results in asymmetric VLAN state across the HSR pair. Fix this by ensuring the cleanup path targets the previously programmed slave device when the second slave fails to add the VID. Signed-off-by: Luka Gejak --- net/hsr/hsr_device.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c index 5c3eca2235ce..6185f9f2630f 100644 --- a/net/hsr/hsr_device.c +++ b/net/hsr/hsr_device.c @@ -534,6 +534,8 @@ static int hsr_ndo_vlan_rx_add_vid(struct net_device *d= ev, { bool is_slave_a_added =3D false; bool is_slave_b_added =3D false; + struct net_device *slave_a_dev =3D NULL; + struct net_device *slave_b_dev =3D NULL; struct hsr_port *port; struct hsr_priv *hsr; int ret =3D 0; @@ -552,11 +554,12 @@ static int hsr_ndo_vlan_rx_add_vid(struct net_device = *dev, /* clean up Slave-B */ netdev_err(dev, "add vid failed for Slave-A\n"); if (is_slave_b_added) - vlan_vid_del(port->dev, proto, vid); + vlan_vid_del(slave_b_dev, proto, vid); return ret; } =20 is_slave_a_added =3D true; + slave_a_dev =3D port->dev; break; =20 case HSR_PT_SLAVE_B: @@ -564,11 +567,12 @@ static int hsr_ndo_vlan_rx_add_vid(struct net_device = *dev, /* clean up Slave-A */ netdev_err(dev, "add vid failed for Slave-B\n"); if (is_slave_a_added) - vlan_vid_del(port->dev, proto, vid); + vlan_vid_del(slave_a_dev, proto, vid); return ret; } =20 is_slave_b_added =3D true; + slave_b_dev =3D port->dev; break; default: break; --=20 2.53.0 From nobody Fri Apr 3 08:34:56 2026 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6696A3FE35C for ; Tue, 24 Mar 2026 14:35:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774362934; cv=none; b=ng54v9faqO21mBEHNO/xi398ZB6Y7MQcolkhtv35uWuPds5EF58jh7ppr7bwqNxIzEEC7d78fTvu7xOKp/EbqxtQj7Vv7CF8nxV4VA8LTW2/T4w0YAxfjCAqg6v6fsPiNOi0hpfUKP/vXYgftKdr7SfXX65DIqR8NC/5SAmp488= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774362934; c=relaxed/simple; bh=wEP0wRbCRZBxROcXg+r+RI888bd1H2e6DUIoY7peRRE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=vEcxRQ0FIwpyRgXe+3YU3P50xya3X5vr1MxyU0KCp3SWxmrx183fdyi9V3979yx1j0HLCHtYhpaeW4tnjtu4Peg+Fq/vwJmf+XLImtccJ90HO26Q8fj7gLj87cXIW++oRWqLFKhY3AVy6Dgjqvt87bD5L/ih8fgTo5sHf6tyzmQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=AwNbKSiZ; arc=none smtp.client-ip=91.218.175.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="AwNbKSiZ" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774362931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HYfBLnylasMK/XC970ogaeLH3TRE02allvnfbVnf3ko=; b=AwNbKSiZtOv9UYh3NIDJlojaJ3FnfVzkNx1hPRZjikoo7+bmVUE1EsX4RCeHhZidDSSWU3 HAxqCxjKoHe1INGoAqUgvByx/wwcxsYXCQ+AC5WJA32BB/Yg7ZSij9EThnVQ/GSJeJ3hy5 H3HcD9Anh1+C0E7935cBpPiv3MuXb6U= From: luka.gejak@linux.dev To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org Cc: horms@kernel.org, fmaurer@redhat.com, liuhangbin@gmail.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, Luka Gejak Subject: [PATCH net-next v1 3/4] net: hsr: require valid EOT supervision TLV Date: Tue, 24 Mar 2026 15:35:02 +0100 Message-ID: <20260324143503.187642-4-luka.gejak@linux.dev> In-Reply-To: <20260324143503.187642-1-luka.gejak@linux.dev> References: <20260324143503.187642-1-luka.gejak@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" From: Luka Gejak Supervision frames are only valid if terminated with a zero-length EOT TLV. The current check fails to reject non-EOT entries as the terminal TLV, potentially allowing malformed supervision traffic. Fix this by strictly requiring the terminal TLV to be HSR_TLV_EOT with a length of zero. Signed-off-by: Luka Gejak Reviewed-by: Felix Maurer --- net/hsr/hsr_forward.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c index aefc9b6936ba..d26c7d0e8109 100644 --- a/net/hsr/hsr_forward.c +++ b/net/hsr/hsr_forward.c @@ -110,7 +110,7 @@ static bool is_supervision_frame(struct hsr_priv *hsr, = struct sk_buff *skb) } =20 /* end of tlvs must follow at the end */ - if (hsr_sup_tlv->HSR_TLV_type =3D=3D HSR_TLV_EOT && + if (hsr_sup_tlv->HSR_TLV_type !=3D HSR_TLV_EOT || hsr_sup_tlv->HSR_TLV_length !=3D 0) return false; =20 --=20 2.53.0 From nobody Fri Apr 3 08:34:56 2026 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA33D3FD15E for ; Tue, 24 Mar 2026 14:35:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774362936; cv=none; b=Zxj908HjxPGJ+XNOeCvpY2/bTO3I/x2RF8jHucIgoSbTjZA4stIyTqIxIQ9W1YSlaLgLOBTtKSFgZ6L97iaR15DMBhP3sbGX8G2DY0WvmuSI8PjxucNnJwDmFhyrhBECNlKVHdYO5lpXs8bIEUzePNvxfUc2VCnqBStJX/FkdGU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774362936; c=relaxed/simple; bh=UXQRM9wPy6fMaUJanJ7vYy07rD58WnCTEhEDvqmvetg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bNtfeBVGm5cuRvG+3+mYLMKHu0oyxLHYD/9//1+ffR02N6IHLh//9apcAU3q6DNOqCBuvdRC86M/TPwefpeluvFL9bmAHUIY1MoSKsEGo/tUQMAuLAnSAksmBRVpeDrxQGP++xYy9l3u/Z651EgFmgzljSWn8CYe2IVctsA3KDU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=hHchKIP8; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="hHchKIP8" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774362933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SQUW0t/0hMtrnhu+SjPyBSdGN05qqOMq7wnGBco7zp8=; b=hHchKIP8mrngisfgAgSyAJ26DObVNiyz3Z9gz3N8kVLPW6MhgUThZFx4fh1Ozz3MewXEw5 gP+6gWMj+CuUDM9EGsVknhGUxDCXD4DzmJ6Rj73PKF8sLDX5niIMwP/s7GpfffUVRLlkDY /Y37GDC6NkoDyy7x5gUcKbjRiEUR+MY= From: luka.gejak@linux.dev To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org Cc: horms@kernel.org, fmaurer@redhat.com, liuhangbin@gmail.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, Luka Gejak Subject: [PATCH net-next v1 4/4] net: hsr: reject unresolved interlink ifindex Date: Tue, 24 Mar 2026 15:35:03 +0100 Message-ID: <20260324143503.187642-5-luka.gejak@linux.dev> In-Reply-To: <20260324143503.187642-1-luka.gejak@linux.dev> References: <20260324143503.187642-1-luka.gejak@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset="utf-8" From: Luka Gejak In hsr_newlink(), a provided but invalid IFLA_HSR_INTERLINK attribute was silently ignored if __dev_get_by_index() returned NULL. This leads to incorrect RedBox topology creation without notifying the user. Fix this by returning -EINVAL and an extack message when the interlink attribute is present but cannot be resolved. Signed-off-by: Luka Gejak Reviewed-by: Felix Maurer --- net/hsr/hsr_netlink.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c index db0b0af7a692..f0ca23da3ab9 100644 --- a/net/hsr/hsr_netlink.c +++ b/net/hsr/hsr_netlink.c @@ -76,9 +76,14 @@ static int hsr_newlink(struct net_device *dev, return -EINVAL; } =20 - if (data[IFLA_HSR_INTERLINK]) + if (data[IFLA_HSR_INTERLINK]) { interlink =3D __dev_get_by_index(link_net, nla_get_u32(data[IFLA_HSR_INTERLINK])); + if (!interlink) { + NL_SET_ERR_MSG_MOD(extack, "Interlink does not exist"); + return -EINVAL; + } + } =20 if (interlink && interlink =3D=3D link[0]) { NL_SET_ERR_MSG_MOD(extack, "Interlink and Slave1 are the same"); --=20 2.53.0