From owner-freebsd-testing@freebsd.org Sat May 2 01:00:52 2020 Return-Path: Delivered-To: freebsd-testing@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EA0222B5EBB for ; Sat, 2 May 2020 01:00:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49DW5J5xxRz4MCg for ; Sat, 2 May 2020 01:00:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id CA6662B5EBA; Sat, 2 May 2020 01:00:52 +0000 (UTC) Delivered-To: testing@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CA2A02B5EB9 for ; Sat, 2 May 2020 01:00:52 +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) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49DW5J529wz4MCd for ; Sat, 2 May 2020 01:00:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A80DA192F9 for ; Sat, 2 May 2020 01:00:52 +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 04210qUC029682 for ; Sat, 2 May 2020 01:00:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 04210quq029681 for testing@freebsd.org; Sat, 2 May 2020 01:00:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: testing@freebsd.org Subject: [Bug 245832] sys.netipsec.tunnel.empty.v{4,6} fail after r359374 Date: Sat, 02 May 2020 01:00:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: tests X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: testing@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 01:00:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D245832 --- Comment #8 from commit-hook@freebsd.org --- A commit references this bug: Author: jhb Date: Sat May 2 01:00:30 UTC 2020 New revision: 360560 URL: https://svnweb.freebsd.org/changeset/base/360560 Log: Don't pass bogus keys down for NULL algorithms. The changes in r359374 added various sanity checks in sessions and requests created by crypto consumers in part to permit backend drivers to make assumptions instead of duplicating checks for various edge cases. One of the new checks was to reject sessions which provide a pointer to a key while claiming the key is zero bits long. IPsec ESP tripped over this as it passes along whatever key is provided for NULL, including a pointer to a zero-length key when an empty string ("") is used with setkey(8). One option would be to teach the IPsec key layer to not allocate keys of zero length, but I went with a simpler fix of just not passing any keys down and always using a key length of zero for NULL algorithms. PR: 245832 Reported by: CI Changes: head/sys/netipsec/xform_ah.c head/sys/netipsec/xform_esp.c --=20 You are receiving this mail because: You are the assignee for the bug.=