In the Linux kernel, the following vulnerability has been resolved:
slip: bound decode() reads against the compressed packet length
slhc_uncompress() parses a VJ-compressed TCP header by advancing a
pointer through the packet via decode() and pull16(). Neither helper
bounds-checks against isize, and decode() masks its return with
& 0xffff so it can never return the -1 that callers test for -- those
error paths are dead code.
A short compressed frame whose change byte requests optional fields
lets decode() read past the end of the packet. The over-read bytes
are folded into the cached cstate and reflected into subsequent
reconstructed packets.
Make decode() and pull16() take the packet end pointer and return -1
when exhausted. Add a bounds check before the TCP-checksum read.
The existing == -1 tests now do what they were always meant to.
CVSS
8.2 HIGH (v3.1, CNA)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 6268f01ae989013671b526c883e92655342c6f6f; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 9aafba2f49e1fcccc2018816f5836a609c925879; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 335957df4ed60f02a2ec0432fbedbf0cc7241d8b; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 37537e42e6df387398bee85cb85070cc80bb1e10; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 4cefe32639933d652614b0bd50f818f9af4af78f; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 0511ecb00e61bf28e2fec4bb41fcce385c3a3b2d; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before d42bec6e4f6d6d658be365539400b3314b76b2a7; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 4c1367a2d7aad643a6f87c6931b13cc1a25e8ca7
from 2.6.12.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.141; from 6.7 before 6.12.91; from 6.13 before 6.18.33; from 6.19 before 7.0.10; 2.6.12; and 4 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.