[Bug 258849] IPSec may generate duplicate SPIs
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 07 Oct 2021 08:41:26 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258849
--- Comment #4 from Mateusz Guzik <mjg@FreeBSD.org> ---
So I don't think this is fixable in a clean manner without significant
refactoring in the area.
I think the pragmatic thing to do here is to try to hoist the sahtree lock out
of key_do_getnewspi. The problem is that there are several callers and callees
to be adjusted which may end up being rather hairy.
As a cop out one can slap an additional lock around all of this, in this
manner:
diff --git a/sys/netipsec/key.c b/sys/netipsec/key.c
index 72c598586d8e..f5da63d7b8f1 100644
--- a/sys/netipsec/key.c
+++ b/sys/netipsec/key.c
@@ -5628,6 +5628,7 @@ key_add(struct socket *so, struct mbuf *m, const struct
sadb_msghdr *mhp)
* secasindex.
* XXXAE: IPComp seems also doesn't use SPI.
*/
+ SPI_ALLOC_LOCK();
if (proto == IPPROTO_TCP) {
sav = key_getsav_tcpmd5(&saidx, &spi);
if (sav == NULL && spi == 0) {
@@ -5648,6 +5649,7 @@ key_add(struct socket *so, struct mbuf *m, const struct
sadb_msghdr *mhp)
}
sav = key_newsav(mhp, &saidx, spi, &error);
+ SPI_ALLOC_UNLOCK();
if (sav == NULL)
return key_senderror(so, m, error);
KEYDBG(KEY_STAMP,
Note this may be turn out to not be a big problem as key_newsav takes rm lock
for writing which already comes with drastic overhead.
Any thoughts on this, ae?
--
You are receiving this mail because:
You are the assignee for the bug.