In the Linux kernel, the following vulnerability has been resolved:
rxrpc: proc: size address buffers for %pISpc output
The AF_RXRPC procfs helpers format local and remote socket addresses into
fixed 50-byte stack buffers with "%pISpc".
That is too small for the longest current-tree IPv6-with-port form the
formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a
dotted-quad tail not only for v4mapped addresses, but also for ISATAP
addresses via ipv6_addr_is_isatap().
As a result, a case such as
[ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535
is possible with the current formatter. That is 50 visible characters, so
51 bytes including the trailing NUL, which does not fit in the existing
char[50] buffers used by net/rxrpc/proc.c.
Size the buffers from the formatter's maximum textual form and switch the
call sites to scnprintf().
Changes since v1:
- correct the changelog to cite the actual maximum current-tree case
explicitly
- frame the proof around the ISATAP formatting path instead of the earlier
mapped-v4 example
CVSS
7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
from 75b54cb57ca34cbe7a87c6ac757c55360a624590 before 386c86412608d3449006a318a662cbcd6ca1f668; from 75b54cb57ca34cbe7a87c6ac757c55360a624590 before 235b2115de892eab2e107a42efa7a4347baaa80b; from 75b54cb57ca34cbe7a87c6ac757c55360a624590 before 625af53a1564e31bb2df9adc3739df46137f46c1; from 75b54cb57ca34cbe7a87c6ac757c55360a624590 before 808a34cdbe8ce336c202d8ea6d5e48496764dc37; from 75b54cb57ca34cbe7a87c6ac757c55360a624590 before a6042b8066b24dbcc7945616a157d4d43e463668; from 75b54cb57ca34cbe7a87c6ac757c55360a624590 before db297c78ce537c9ac96f0eda9b25ad72c8caefa9; 75b54cb57ca34cbe7a87c6ac757c55360a624590 builds before 10ebed83f9f6414af4e85bc85ffaeda7effdd874; from 75b54cb57ca34cbe7a87c6ac757c55360a624590 before a44ce6aa2efb61fe44f2cfab72bb01544bbca272
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.