CVE-2022-50279 in Linux
Riassunto
di VulDB • 19/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
wifi: rtlwifi: Correzione del bug global-out-of-bounds in _rtl8812ae_phy_set_txpower_limit()
È stato segnalato un errore global-out-of-bounds da KASAN:
BUG: KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
Lettura di dimensione 1 all'indirizzo ffffffffa0773c43 da parte del task NetworkManager/411
CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ... kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]
rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]
... </TASK>
La causa radice del problema è che l'ordine di confronto di "prate_section" in _rtl8812ae_phy_set_txpower_limit() è errato. La funzione _rtl8812ae_eq_n_byte() viene utilizzata per confrontare i primi n byte delle due stringe dall'ultima alla prima (da tail a head), il che causa il problema. In _rtl8812ae_phy_set_txpower_limit(), l'intenzione originale era soddisfare questo requisito progettando attentamente l'ordine di confronto. Ad esempio, "pregulation" e "pbandwidth" vengono confrontati in ordine di lunghezza, dal più piccolo al più grande, partendo da 3 e terminando con 4. Tuttavia, l'ordine di confronto di "prate_section" non segue tale requisito di ordine; pertanto, quando "prate_section" è "HT", il confronto dall'ultima alla prima byte porta a un accesso fuori dai limiti (_out-of-bounds_) in _rtl8812ae_eq_n_byte(). Come menzionato sopra, _rtl8812ae_eq_n_byte() ha la stessa funzione di strcmp(), quindi l'uso di strcmp() è sufficiente.
La correzione consiste nel rimuovere _rtl8812ae_eq_n_byte() e utilizzare esclusivamente strcmp(). Sebbene il problema possa essere risolto regolando l'ordine di confronto di "prate_section", ciò potrebbe causare il fatto che il valore di "rate_section" non sia compreso tra 0 e 5. Inoltre, il commit "21e4b0726dc6" non solo ha spostato il driver dalla directory staging al ramo principale (regular tree), ma ha anche aggiunto la funzione di impostazione del limite di potenza di trasmissione (txpower limit) durante la fase di configurazione del driver; è stato quindi questo commit a introdurre il problema.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.