| Message ID | 20231105202936.25694-1-s.shtylyov@omp.ru (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 86222a8fc16ec517de8da2604d904c9df3a08e5d |
| Headers | show |
| Series | pstore: ram_core: fix possible overflow in persistent_ram_init_ecc() | expand |
On Sun, 05 Nov 2023 23:29:36 +0300, Sergey Shtylyov wrote: > In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return > 64-bit value since persistent_ram_zone::buffer_size has type size_t which > is derived from the 64-bit *unsigned long*, while the ecc_blocks variable > this value gets assigned to has (always 32-bit) *int* type. Even if that > value fits into *int* type, an overflow is still possible when calculating > the size_t typed ecc_total variable further below since there's no cast to > any 64-bit type before multiplication. Declaring the ecc_blocks variable > as *unsigned long* should fix this mess... > > [...] I changed this from unsigned long to size_t, which will do the same thing. Applied to for-linus/pstore, thanks! [1/1] pstore: ram_core: fix possible overflow in persistent_ram_init_ecc() https://git.kernel.org/kees/c/c92116e01d32 Take care,
On 12/2/23 11:47 PM, Kees Cook wrote: [...] >> In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return >> 64-bit value since persistent_ram_zone::buffer_size has type size_t which >> is derived from the 64-bit *unsigned long*, while the ecc_blocks variable >> this value gets assigned to has (always 32-bit) *int* type. Even if that >> value fits into *int* type, an overflow is still possible when calculating >> the size_t typed ecc_total variable further below since there's no cast to >> any 64-bit type before multiplication. Declaring the ecc_blocks variable >> as *unsigned long* should fix this mess... >> >> [...] > > I changed this from unsigned long to size_t, which will do the same thing. Not quite the same. And ecc_blocks is a block count, not a byte count, so size_t doesn't seem appropriate... > Applied to for-linus/pstore, thanks! > > [1/1] pstore: ram_core: fix possible overflow in persistent_ram_init_ecc() > https://git.kernel.org/kees/c/c92116e01d32 > > Take care, Thanks anyway. :-) MBR, Sergey
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index 650e437b55e6..131c1923b8c0 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -190,7 +190,7 @@ static int persistent_ram_init_ecc(struct persistent_ram_zone *prz, { int numerr; struct persistent_ram_buffer *buffer = prz->buffer; - int ecc_blocks; + unsigned long ecc_blocks; size_t ecc_total; if (!ecc_info || !ecc_info->ecc_size)
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return 64-bit value since persistent_ram_zone::buffer_size has type size_t which is derived from the 64-bit *unsigned long*, while the ecc_blocks variable this value gets assigned to has (always 32-bit) *int* type. Even if that value fits into *int* type, an overflow is still possible when calculating the size_t typed ecc_total variable further below since there's no cast to any 64-bit type before multiplication. Declaring the ecc_blocks variable as *unsigned long* should fix this mess... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 9cc05ad97c57 ("staging: android: persistent_ram: refactor ecc support") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> --- The patch is against the 'master' branch of Linus Torvalds' repo. fs/pstore/ram_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)