[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <B024C29C-96D4-4F92-B2EF-F01CB06B27DF@nvidia.com>
Date: Sat, 01 Mar 2025 12:05:36 -0500
From: Zi Yan <ziy@...dia.com>
To: Ethan Carter Edwards <ethan@...ancedwards.com>
Cc: Hugh Dickins <hughd@...gle.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] mm/shmem: fix uninitialized scalar variable
On 1 Mar 2025, at 11:57, Ethan Carter Edwards wrote:
> int entry_order has the possibility of being uninitialized when
> returning. Initializing it to zero at declaration appeases coverity and
> reduces risk of returning nonsense.
How come?
After entry_order is declared, for (;;) begins. The first branch
is "if (!xa_is_value(old) || swp_to_radix_entry(swap) != old)", in
the then case, xas_set_err(&xas, -EEXIST), which makes
"if (!xas_nomem(&xas, gfp))" at the end of the for loop to break.
Then "if (xas_error(&xas))" will return -EEXIST. If the first then branch
is not taken, entry_order is assigned to xas_get_order(&xas).
Which code path would make entry_order uninitialized?
Thanks.
>
> Closes: https://scan7.scan.coverity.com/#/project-view/53698/11354?selectedIssue=1637878
> Fixes: 6dbc440b79b6 ("mm/shmem: use xas_try_split() in shmem_split_large_entry()")
> Signed-off-by: Ethan Carter Edwards <ethan@...ancedwards.com>
> ---
> mm/shmem.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index d19d33e98320d5e0ccbc86616bb3ea30d29f0cc1..3718c71aba9304dd3ca8df137a19e0564b8aadb2 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2153,7 +2153,8 @@ static int shmem_split_large_entry(struct inode *inode, pgoff_t index,
> {
> struct address_space *mapping = inode->i_mapping;
> XA_STATE_ORDER(xas, &mapping->i_pages, index, 0);
> - int split_order = 0, entry_order;
> + int split_order = 0;
> + int entry_order = 0;
> int i;
>
> /* Convert user data gfp flags to xarray node gfp flags */
>
> ---
> base-commit: c0eb65494e59d9834af7cbad983629e9017b25a1
> change-id: 20250301-entry_order_uninit-129251b1ac9f
>
> Best regards,
> --
> Ethan Carter Edwards <ethan@...ancedwards.com>
--
Best Regards,
Yan, Zi
Powered by blists - more mailing lists