RE: [PATCH] wifi: rtw88: fix out-of-bounds CAM write when key table is full

[Ping-Ke Shih <pkshih@realtek.com>]

イムティヤズ <reza1234khan1234@gmail.com> wrote:
> In rtw_ops_set_key(), when the CAM table is full,
> rtw_sec_get_free_cam() returns RTW_MAX_SEC_CAM_NUM (32) because
> find_next_zero_bit()/find_first_zero_bit() return the bitmap size
> when no free slot exists. The bounds check compares the returned
> index with ">" against total_cam_num (32), so the invalid index 32
> passes the check.
> 
> rtw_sec_write_cam() then indexes cam_table[32], an array declared
> with RTW_MAX_SEC_CAM_NUM (32) entries, causing an out-of-bounds
> write that corrupts the cam_map allocation bitmap. The write also
> sets bit 32 of cam_map, which overruns the bitmap as well.
> 
> Fix the off-by-one by rejecting indices >= total_cam_num.
> 
> Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
> Cc: stable@vger.kernel.org

These two are formal tags, so I'd move them together with Tested-by tag.

> 
> Tested on: RTL8821CE (PCIe) on kernel
> 7.2.0-rc6-rtw88test-00059-g0d8395707651. The patched module loaded
> and associated to a WPA2 network; ping traffic passed with 0% packet
> loss. Reassociation and disconnect/reconnect cycles completed
> without errors, and the CAM table (debugfs dump_cam) showed valid
> key entries. The CAM-full boundary (28+ pairwise keys) requires an
> access point with 28+ clients and is not reachable in a
> single-client setup, so that path was verified by code inspection.

Yes. Unless you start an AP mode, and use many clients connect it, but
I suspect rtw88 can't afford to support such clients. 

> 
> Tested-by: イムティヤズ <reza1234khan1234@gmail.com>
> Signed-off-by: イムティヤズ <reza1234khan1234@gmail.com>

By the way, if you want spell your Japanese name in English, the display would
be normal since my some git tools do not support UTF-8. But I don't insist this.

Acked-by: Ping-Ke Shih <pkshih@realtek.com>