Bug 2266270 (CVE-2021-46906)

Summary:	CVE-2021-46906 kernel: info leak in hid_submit_ctrl
Product:	[Other] Security Response	Reporter:	Rohit Keshri <rkeshri>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	acaringi, allarkin, aquini, bhu, chwhite, cye, cyin, dbohanno, debarbos, dfreiber, drow, dvlasenk, esandeen, ezulian, hkrzesin, jarod, jburrell, jdenham, jfaracco, jforbes, jlelli, joe.lawrence, jshortt, jstancek, jwyatt, kcarcia, ldoskova, lgoncalv, lzampier, mleitner, mmilgram, mstowell, nmurray, ptalbert, rogbas, rparrazo, rrobaina, rvrbovsk, rysulliv, scweaver, sukulkar, tglozar, tyberry, vkumar, wcosta, williams, wmealing, ycote, ykopkova, zhijwang
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:	A flaw was found in the Linux kernel. This issue is caused by an information leak in hid_submit_ctrl.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	2266272
Bug Blocks:	2266269

Description Rohit Keshri 2024-02-27 11:56:04 UTC

In the Linux kernel, the following vulnerability has been resolved:

HID: usbhid: fix info leak in hid_submit_ctrl

In hid_submit_ctrl(), the way of calculating the report length doesn't
take into account that report->size can be zero. When running the
syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to
calculate transfer_buffer_length as 16384. When this urb is passed to
the usb core layer, KMSAN reports an info leak of 16384 bytes.

To fix this, first modify hid_report_len() to account for the zero
report size case by using DIV_ROUND_UP for the division. Then, call it
from hid_submit_ctrl().

https://git.kernel.org/stable/c/0e280502be1b003c3483ae03fc60dea554fcfa82
https://git.kernel.org/stable/c/21883bff0fd854e07429a773ff18f1e9658f50e8
https://git.kernel.org/stable/c/41b1e71a2c57366b08dcca1a28b0d45ca69429ce
https://git.kernel.org/stable/c/6be388f4a35d2ce5ef7dbf635a8964a5da7f799f
https://git.kernel.org/stable/c/7f5a4b24cdbd7372770a02f23e347d7d9a9ac8f1
https://git.kernel.org/stable/c/8c064eece9a51856f3f275104520c7e3017fc5c0
https://git.kernel.org/stable/c/b1e3596416d74ce95cc0b7b38472329a3818f8a9
https://git.kernel.org/stable/c/c5d3c142f2d57d40c55e65d5622d319125a45366

Comment 1 Rohit Keshri 2024-02-27 12:07:20 UTC

Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 2266272]

Comment 4 Justin M. Forbes 2024-02-27 19:09:34 UTC

This was fixed for Fedora with the 5.12.12 stable kernel updates.

Comment 8 Alex 2024-06-09 16:59:52 UTC

The result of automatic check (that is developed by Alexander Larkin) for this CVE-2021-46906 is: CHECK	Maybe valid. Check manually. with impact LOW (that is an approximation based on flags KASAN USB SIMPLEFIX LEAK  ; these flags parsed automatically based on patch data). Such automatic check happens only for Low/Moderates (and only when not from reporter, but parsing already existing CVE). Highs always checked manually (I check it myself and then we check it again in Remediation team). In rare cases some of the Moderates could be increased to High later.