diff options
| author | Eliot Courtney <ecourtney@nvidia.com> | 2026-09-30 11:42:51 +0900 |
|---|---|---|
| committer | Miguel Ojeda <ojeda@kernel.org> | 2026-10-13 12:52:01 +0200 |
| commit | 931790a91378f6513ba82730eb5607479c3184a0 (patch) | |
| tree | cf56178f419b39d4f809a460c44806cce0f45e25 /scripts/Makefile.thinlto | |
| parent | 8d26ced7b496f4cb9c5eafbad7ee21adf0fb6673 (diff) | |
| download | linux-931790a91378f6513ba82730eb5607479c3184a0.tar.gz linux-931790a91378f6513ba82730eb5607479c3184a0.zip | |
rust: bitmap: restrict bitmap length to at most i32::MAX
It is currently possible to construct a non-`BitmapVec` backed `Bitmap`
using `Bitmap::from_raw` that is larger than `i32::MAX`, and it is not
part of the unsafe requirements. Restricting all bitmaps (even
non-`BitmapVec` backed ones) to a maximum size of `i32::MAX` simplifies
a few things and matches `BitmapVec::MAX_LEN`. For example,
`copy_and_extend` truncates `len` to u32, which is wrong for > u32::MAX
size. `__bitmap_set` and `__bitmap_clear` need i32 for `size` and u32
for `start` - so they can't be run on a `Bitmap` with a > i32::MAX size.
Rather than adding runtime checks to account for the case of a non
`BitmapVec` backed `Bitmap`, just include that in the requirements for
`Bitmap`.
Add that requirement to the unsafe requirements on `Bitmap::from_raw`
and `Bitmap::from_raw_mut`, and to the invariants on `Bitmap`.
This also fixes u32 casts truncating in `copy_and_extend`, which could
otherwise lead to OOB writes.
Fixes: 11eca92a2cae ("rust: add bitmap API.")
Link: https://lore.kernel.org/DKG0U8RLO7LZ.2I1AIH0S38PAP@nvidia.com
Reviewed-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: Burak Emir <burak.emir@gmail.com>
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260930-chid-v9-2-0d6cca376cff@nvidia.com
Cc: stable@vger.kernel.org
[ Added a few intra-doc links. Added backticks to C types. Capitalize
tagged comments. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Diffstat (limited to 'scripts/Makefile.thinlto')
0 files changed, 0 insertions, 0 deletions
