libnl issue draft
Title
xfrm: bound the alg_name copy in XFRMA_ALG_AUTH handling
Body
Hi libnl folks,
I rechecked current main at 655a638d4e1f74be9256a3108ae2abb84827a9ce, and this xfrm path still looks unsafe.
In lib/xfrm/sa.c, the XFRMA_ALG_AUTH path allocates sa->auth and then copies the algorithm name with:
strcpy(sa->auth->alg_name, auth->alg_name);
Both the source and destination use fixed 64-byte alg_name arrays, but the code does not prove that the incoming netlink blob is actually NUL-terminated before calling strcpy(). If the attribute is malformed, or if it fills the 64-byte field without a trailing NUL, the copy can run past the end of the destination.
I checked the last 20 days of public GitHub issues and pull requests for this sink and did not find a matching report.
A safer fix would be to treat the incoming name as bounded data, validate termination before copying, or switch to a bounded copy that respects the real destination size.
libnl issue draft
Title
xfrm: bound the
alg_namecopy inXFRMA_ALG_AUTHhandlingBody
Hi libnl folks,
I rechecked current
mainat655a638d4e1f74be9256a3108ae2abb84827a9ce, and this xfrm path still looks unsafe.In
lib/xfrm/sa.c, theXFRMA_ALG_AUTHpath allocatessa->authand then copies the algorithm name with:Both the source and destination use fixed 64-byte
alg_namearrays, but the code does not prove that the incoming netlink blob is actually NUL-terminated before callingstrcpy(). If the attribute is malformed, or if it fills the 64-byte field without a trailing NUL, the copy can run past the end of the destination.I checked the last 20 days of public GitHub issues and pull requests for this sink and did not find a matching report.
A safer fix would be to treat the incoming name as bounded data, validate termination before copying, or switch to a bounded copy that respects the real destination size.