From: sashiko-bot@kernel.org
To: "Tariq Toukan" <tariqt@nvidia.com>
Cc: linux-rdma@vger.kernel.org
Subject: Re: [PATCH net 3/3] net/mlx5: DR, Fix out-of-bounds write when sync to HW fails
Date: Wed, 21 Oct 2026 08:00:30 +0000 [thread overview]
Message-ID: <sashiko-outbox-179935@kernel.org> (raw)
In-Reply-To: <20261021074949.3471704-4-tariqt@nvidia.com>
> From: Yevgeny Kliteynik <kliteyn@nvidia.com>
>
> mlx5dr_icm_free_chunk() moves a freed chunk to the "hot" chunks array by
> writing it to hot_chunks_arr and, once the accumulated hot memory
> crosses a threshold, triggers a sync to HW that flushes the array. The
> array is large enough to hold the chunks of a single accumulation cycle,
> and relies on the sync path to flush it.
>
> However, if sync to HW fails, hot chunks array is not cleared, and every
> subsequent mlx5dr_icm_free_chunk will write past the end of
> hot_chunks_arr, resulting in an out-of-bounds write and kernel heap
> corruption.
>
> A failed sync to HW also means it is no longer safe to recycle ICM: a
> chunk's memory may only be returned to the buddy allocator (and thus be
> reused) after a sync has confirmed that HW no longer references it.
>
> Fix both problems by putting the pool into an error state when a sync to
> HW fails - mlx5dr_icm_free_chunk() stops queuing freed chunks, so it
> never writes past hot_chunks_arr. The chunk's ICM memory is not returned
> to the buddy allocator (HW may still reference it); the segment is left
> reserved and is reclaimed when the pool is destroyed.
>
> Fixes: 4519fc45beeb ("net/mlx5: DR, Keep track of hot ICM chunks in an array instead of list")
> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
> Reviewed-by: Alex Vesker <valex@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261021074949.3471704-1-tariqt@nvidia.com?part=3
next prev parent reply other threads:[~2026-10-21 8:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 7:49 [PATCH net 0/3] net/mlx5: Fix HWS and DR steering memory safety bugs Tariq Toukan
2026-10-21 7:49 ` [PATCH net 1/3] net/mlx5: HWS, Handle NULL in vport destination action creation Tariq Toukan
2026-10-21 8:00 ` sashiko-bot
2026-10-21 7:49 ` [PATCH net 2/3] net/mlx5: HWS, Fix heap buffer overflow in insert header action Tariq Toukan
2026-10-21 8:00 ` sashiko-bot
2026-10-23 10:52 ` netdev-bot+sashiko
2026-10-21 7:49 ` [PATCH net 3/3] net/mlx5: DR, Fix out-of-bounds write when sync to HW fails Tariq Toukan
2026-10-21 8:00 ` sashiko-bot [this message]
2026-10-23 10:52 ` netdev-bot+sashiko
2026-10-27 8:56 ` Paolo Abeni
2026-10-21 7:53 ` [PATCH net 0/3] net/mlx5: Fix HWS and DR steering memory safety bugs netdev-bot+sinfo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-179935@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.