From nobody Tue Dec 17 12:28:35 2024 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YCGLr0SgDz5h8dr for ; Tue, 17 Dec 2024 12:28:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YCGLq4r5vz4ZTk for ; Tue, 17 Dec 2024 12:28:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1734438515; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=P61woLo8rZN+KFYo+GHJEaJ+uVSAuK4AKs2gZwst8T0=; b=eqNotgY0wz4gZ3rLCisVGzayxrNKmYM6+G/G+aVrpdccaXNCjwRHJAV3Cv1YMSg6Zs/X4P I9zAowmIt65U5MWpr7DZsNnPm5t2PSbsVnlzJyZZD4UIIXm6/csTQ61xvqlMspX3AOe4Ah 4T/UrcDhqNulMrYbxbRIHRQb4dGi17D96GhklZ1lbt2N7kRe+5c13y2E1xPBlMsDe+VSyd dT4OJOW9Bz9z1wjEFtNabPCuiOLf3RQuDXM+h3tmUt+rAhFSjGhrTdK7n99sej1aC4NRHf wGhn7lVjfwDaYWbUalpJCyANg80SigxG3sJlnYIuiZWm4ichgs+B6I5mYdIvCQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1734438515; a=rsa-sha256; cv=none; b=Bag67c/OmkUqsiLFcPB38sqD6kMhGKT8+JRocNyGlEdCE3LA7pnhSd/1gLzpX4Ld64sM3B 7ZzLjdSg9eJTKJD6L3qNX6GYyqV2XVnHZnhoUuiAQosoSgOwucWZtdRlSyo5y6plXI2m2T xenrfqRjibrKCOAUi0IX5GyJYHOZJO2ad0pL404T7yEW1FCsspVsQ+izytAgXMwe5YLmeT MU1V2h7oeI8MWK9TqWX77D2alqz2rXxBZjuuZ8fwhSSxao0CKPlKYSPGVUOwmoChMghrQl xsPS+M4Or7ZHcy5iNMRKOGvl4QvootU8aASnwUOQMHNlDdvqGGUNnExI61/SuA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4YCGLq4RWQzNC0 for ; Tue, 17 Dec 2024 12:28:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4BHCSZd9067601 for ; Tue, 17 Dec 2024 12:28:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4BHCSZn8067600 for bugs@FreeBSD.org; Tue, 17 Dec 2024 12:28:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 283380] accepts and processes IPv4 packets destined to non-local MAC addresses instead of dropping them Date: Tue, 17 Dec 2024 12:28:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 14.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: jgm@osn.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283380 Bug ID: 283380 Summary: accepts and processes IPv4 packets destined to non-local MAC addresses instead of dropping them Product: Base System Version: 14.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: jgm@osn.de FreeBSD 14.1-RELEASE-p5 running on Proxmox VE 8.2 with Open vSwitch using v= tnet devices the system accepts and forwards IP packets to non-local MAC addresses which= can be seen on a tcpdump eg tcpdump -netttti vtnet2 host 146.185.xx.yy the MAC address on our vtnet interface is bc:24:11:xx:yy:zz fc:0a:81:xx:yy:zz and 48:f8:db:xx:yy:zz are both non-local/unknown MAC addresses 2024-12-17 13:00:49.618676 fc:0a:81:xx:yy:zz > 48:f8:db:xx:yy:zz, ethertype IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.= ], seq 600:625, ack 636, win 126, length 25 2024-12-17 13:00:49.618687 bc:24:11:xx:yy:zz > 20:50:0f:xx:yy:zz, ethertype IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.= ], seq 600:625, ack 636, win 126, length 25 2024-12-17 13:00:49.618910 bc:24:11:xx:yy:zz > 20:50:0f:xx:yy:zz, ethertype IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.= ], seq 600:625, ack 636, win 126, length 25 2024-12-17 13:00:54.619698 fc:0a:81:xx:yy:zz > 48:f8:db:xx:yy:zz, ethertype IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.= ], seq 650:675, ack 687, win 126, length 25 2024-12-17 13:00:54.619715 bc:24:11:xx:yy:zz > 20:50:0f:xx:yy:zz, ethertype IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.= ], seq 650:675, ack 687, win 126, length 25 2024-12-17 13:00:54.619762 bc:24:11:xx:yy:zz > 20:50:0f:xx:yy:zz, ethertype IPv4 (0x0800), length 79: 146.185.xx.yy.443 > 217.76.xx.yy.60299: Flags [P.= ], seq 650:675, ack 687, win 126, length 25 The FreeBSD system "sees" a packet which is flooded on the network because = of the unknown destination MAC address. The problem is that this packet is process= ed and forwarded by the kernel. The MAC 20:50:0f:xx:yy:zz is the correct MAC address of the next hop. Which means the kernel does a route table lookup and forwards the packet to the "correct" n= ext hop which causes duplicates on the receiving end. Furthermore it looks like the kernel itself generates a duplicate of this packet and sent it twice. I would expect that those packets are simple dropped by the kernel. --=20 You are receiving this mail because: You are the assignee for the bug.=