summaryrefslogtreecommitdiff
path: root/rust/helpers/vmalloc.c
diff options
context:
space:
mode:
authorGui-Dong Han <hanguidong02@gmail.com>2025-11-20 20:06:57 +0800
committerPaolo Abeni <pabeni@redhat.com>2025-11-25 12:39:26 +0100
commit82fca3d8a4a34667f01ec2351a607135249c9cff (patch)
tree4560d80d57658339d003ebd1a0051c7f7a607c6e /rust/helpers/vmalloc.c
parentf98e3ca2e4306a0c9deba1769248b25859db8a3d (diff)
atm/fore200e: Fix possible data race in fore200e_open()
Protect access to fore200e->available_cell_rate with rate_mtx lock in the error handling path of fore200e_open() to prevent a data race. The field fore200e->available_cell_rate is a shared resource used to track available bandwidth. It is concurrently accessed by fore200e_open(), fore200e_close(), and fore200e_change_qos(). In fore200e_open(), the lock rate_mtx is correctly held when subtracting vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth. However, if the subsequent call to fore200e_activate_vcin() fails, the function restores the reserved bandwidth by adding back to available_cell_rate without holding the lock. This introduces a race condition because available_cell_rate is a global device resource shared across all VCCs. If the error path in fore200e_open() executes concurrently with operations like fore200e_close() or fore200e_change_qos() on other VCCs, a read-modify-write race occurs. Specifically, the error path reads the rate without the lock. If another CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in fore200e_close()) between this read and the subsequent write, the error path will overwrite the concurrent update with a stale value. This results in incorrect bandwidth accounting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251120120657.2462194-1-hanguidong02@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'rust/helpers/vmalloc.c')
0 files changed, 0 insertions, 0 deletions