In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop
rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter
Negotiation) frame without checking for zero. When the remote peer
sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg
path to enter an infinite loop when fragmenting data, as each fragment
has size == min_t(size_t, len, 0) == 0, so the remaining length never
decreases. The infinite allocation of zero-length skbs exhausts all
system memory.
Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated
value is zero, consistent with the initial value assigned in
rfcomm_dlc_alloc().
from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before e7c0aa45ae6c5a338661b23812bfcdef50bf3e96; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before cbc2962da99b6b89345267d3aa74b4b573340548; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 9b2e5f1928c99224345a9ed8c5dae5fc74964d6d; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before fc4851ff8dfb505e9a19efcc286712132bbd178d; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before f561e44261344adadf9d6a6dff31e3af9776d5c6; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before aeee917a4878af95f0c63e18c5f22eaf6299c7b8; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 3988cbb1be501dbff909a2ee024670e3c955a66d; from 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 before 44c98fd082eafd49d55a8a4077ff488175b2fe24
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.