In the Linux kernel, the following vulnerability has been resolved:
net: tls: prevent chain-after-chain in plain text SG
Sashiko points out that if end = 0 (start != 0) the current
code will create a chain link to content type right after
the wrap link:
This would create a chain where the wrap link points directly
to another chain link. The scatterlist API sg_next iterator
does not recursively resolve consecutive chain links.
meaning this is illegal input to crypto.
The wrapping link is unnecessary if end = 0. end is the entry after
the last one used so end = 0 means there's nothing pushed after
the wrap:
end start i
v v v
[ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]
Skip the wrapping in this case.
TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0.
This avoids the chain-after-chain.
Move the wrap chaining before marking END and chaining off content
type, that feels like more logical ordering to me, but should not
matter from functional perspective.
from 9aaaa56845a06aeabdd597cbe19492dc01f281ec before 49a5faaa471ddcd37b6893970c9916eb836e7c31; from 9aaaa56845a06aeabdd597cbe19492dc01f281ec before 91359966e247c0244c66d50bbb8e74aefa4321c3; from 9aaaa56845a06aeabdd597cbe19492dc01f281ec before 410351158dfef2d67fea6603680b3a6013c6ed9d; from 9aaaa56845a06aeabdd597cbe19492dc01f281ec before acdc12b71c9aa4be5dcd2c8062753c6d2033e235; from 9aaaa56845a06aeabdd597cbe19492dc01f281ec before 929b1548e63ac72e104c07d8ee8cbbeeba2fa89a; from 9aaaa56845a06aeabdd597cbe19492dc01f281ec before af855f4c966afafef74faf8390c7b86568c0d46d; from 9aaaa56845a06aeabdd597cbe19492dc01f281ec before b9c015ef1a7bf1e8dc67f21c6381f36deb2c3a36; from 9aaaa56845a06aeabdd597cbe19492dc01f281ec before ff26a0e8377dec07e4a7230db7675bed1b9a6d03; and 2 more ranges
from 5.4.14 before 5.5; from 5.5.1 before 5.10.258; from 5.11 before 5.15.209; from 5.16 before 6.1.175; from 6.2 before 6.6.142; from 6.7 before 6.12.92; from 6.13 before 6.18.34; from 6.19 before 7.0.11; and 5 more ranges
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.
