Date: Sat, 02 May 2020 01:00:52 +0000
From: bugzilla-noreply@freebsd.org
To: testing@freebsd.org
Subject: [Bug 245832] sys.netipsec.tunnel.empty.v{4,6} fail after r359374
Message-ID: <bug-245832-32464-VsaCdkCrC9@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-245832-32464@https.bugs.freebsd.org/bugzilla/>
References: <bug-245832-32464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-245832-32464-VsaCdkCrC9>