In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix mismatched free of HalData in rtw_sdio_if1_init()
padapter->HalData is allocated via vzalloc(), but incorrectly freed
using kfree() in the rtw_sdio_if1_init() error path. Using kfree() to
release this vmalloc-backed buffer can lead to memory corruption.
Use rtw_hal_data_deinit() to pair the free correctly and free
HalData with vfree().
The bug was first flagged by an experimental static analysis tool we
are developing for kernel memory-management bugs. Manual inspection
confirms that the issue is still present in current mainline.
An x86_64 allyesconfig build showed no new warnings. As we do not have
suitable RTL8723BS SDIO hardware to test with, no runtime testing was
able to be performed.
CVSS
5.5 MEDIUM (v3.1, NVD)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
from 554c0a3abf216c991c5ebddcdb2c08689ecd290b before ff6d1ba247b5c62bdb678f1069abc86ad88a1402; from 554c0a3abf216c991c5ebddcdb2c08689ecd290b before d6158333d630a1b21d8914feaf77a6f5deb185d9; 554c0a3abf216c991c5ebddcdb2c08689ecd290b builds before 6c017ab2b0e1b60b5be94636c94720347213d78b; from 554c0a3abf216c991c5ebddcdb2c08689ecd290b before 4520d673d49dabfd42c008a33889251025f7d6d5; from 554c0a3abf216c991c5ebddcdb2c08689ecd290b before 423574feaed192063ef0cd0813fb85425f39e539; from 554c0a3abf216c991c5ebddcdb2c08689ecd290b before 737c928ff5092d7e55128a232c231248fc993777; from 554c0a3abf216c991c5ebddcdb2c08689ecd290b before 911190f0b9511c3c81f2f2484414c1ae26f636b3; from 554c0a3abf216c991c5ebddcdb2c08689ecd290b before 264676418b726baca7be49171e306b6aa05cceb0
from 4.12 before 5.10.270; from 5.11 before 5.15.221; from 5.16 before 6.1.188; from 6.2 before 6.6.157; from 6.7 before 6.12.110; from 6.13 before 6.18.52; from 6.19 before 7.2.6
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.