Coverity: scan_swap_map(): Memory - corruptions

Coverity: scan_swap_map(): Memory - corruptions

[coverity-bot]

Hello!

This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20200422 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan

You're getting this email because you were associated with the identified
lines of code (noted below) that were touched by commits:

  Wed Feb 22 15:45:33 2017 -0800
    36005bae205d ("mm/swap: allocate swap slots in batches")

Coverity reported the following:

*** CID 1492705:  Memory - corruptions  (OVERRUN)
/mm/swapfile.c: 972 in scan_swap_map()
966     static unsigned long scan_swap_map(struct swap_info_struct *si,
967     				   unsigned char usage)
968     {
969     	swp_entry_t entry;
970     	int n_ret;
971
vvv     CID 1492705:  Memory - corruptions  (OVERRUN)
vvv     Overrunning struct type swp_entry_t of 8 bytes by passing it to a function which accesses it at byte offset 15.
972     	n_ret = scan_swap_map_slots(si, usage, 1, &entry);
973
974     	if (n_ret)
975     		return swp_offset(entry);
976     	else
977     		return 0;

If this is a false positive, please let us know so we can mark it as
such, or teach the Coverity rules to be smarter. If not, please make
sure fixes get into linux-next. :) For patches fixing this, please
include these lines (but double-check the "Fixes" first):

Human edit:
I can't tell if this is a false positive. The detailed analysis points
at:

844        si->cluster_next = offset + 1;
   	67. index_const: Pointer slots directly indexed by n_ret++ with value 1.
845        slots[n_ret++] = swp_entry(si->type, offset);

It has an execution path that reaches there, but I don't know if it's
actually possible...

Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
Addresses-Coverity-ID: 1492705 ("Memory - corruptions")
Fixes: 36005bae205d ("mm/swap: allocate swap slots in batches")

Thanks for your attention!

-- 
Coverity-bot

Re: Coverity: scan_swap_map(): Memory - corruptions

[Huang, Ying]

coverity-bot <keescook@chromium.org> writes:

> Hello!
>
> This is an experimental semi-automated report about issues detected by
> Coverity from a scan of next-20200422 as part of the linux-next scan project:
> https://scan.coverity.com/projects/linux-next-weekly-scan
>
> You're getting this email because you were associated with the identified
> lines of code (noted below) that were touched by commits:
>
>   Wed Feb 22 15:45:33 2017 -0800
>     36005bae205d ("mm/swap: allocate swap slots in batches")
>
> Coverity reported the following:
>
> *** CID 1492705:  Memory - corruptions  (OVERRUN)
> /mm/swapfile.c: 972 in scan_swap_map()
> 966     static unsigned long scan_swap_map(struct swap_info_struct *si,
> 967     				   unsigned char usage)
> 968     {
> 969     	swp_entry_t entry;
> 970     	int n_ret;
> 971
> vvv     CID 1492705:  Memory - corruptions  (OVERRUN)
> vvv     Overrunning struct type swp_entry_t of 8 bytes by passing it to a function which accesses it at byte offset 15.
> 972     	n_ret = scan_swap_map_slots(si, usage, 1, &entry);
> 973
> 974     	if (n_ret)
> 975     		return swp_offset(entry);
> 976     	else
> 977     		return 0;
>
> If this is a false positive, please let us know so we can mark it as
> such, or teach the Coverity rules to be smarter. If not, please make
> sure fixes get into linux-next. :) For patches fixing this, please
> include these lines (but double-check the "Fixes" first):
>
> Human edit:
> I can't tell if this is a false positive. The detailed analysis points
> at:
>
> 844        si->cluster_next = offset + 1;
>    	67. index_const: Pointer slots directly indexed by n_ret++ with value 1.
> 845        slots[n_ret++] = swp_entry(si->type, offset);

If my understanding were correct, this will not cause problem.  Because
in the next line,

   /* got enough slots or reach max slots? */
   if ((n_ret == nr) || (offset >= si->highest_bit))
           goto done;

The value of n_ret will be checked and function will return if n_ret==1
because nr==1.

Best Regards,
Huang, Ying

Re: Coverity: scan_swap_map(): Memory - corruptions

[Kees Cook]

On Thu, Apr 23, 2020 at 01:57:50PM +0800, Huang, Ying wrote:
> coverity-bot <keescook@chromium.org> writes:
> 
> > Hello!
> >
> > This is an experimental semi-automated report about issues detected by
> > Coverity from a scan of next-20200422 as part of the linux-next scan project:
> > https://scan.coverity.com/projects/linux-next-weekly-scan
> >
> > You're getting this email because you were associated with the identified
> > lines of code (noted below) that were touched by commits:
> >
> >   Wed Feb 22 15:45:33 2017 -0800
> >     36005bae205d ("mm/swap: allocate swap slots in batches")
> >
> > Coverity reported the following:
> >
> > *** CID 1492705:  Memory - corruptions  (OVERRUN)
> > /mm/swapfile.c: 972 in scan_swap_map()
> > 966     static unsigned long scan_swap_map(struct swap_info_struct *si,
> > 967     				   unsigned char usage)
> > 968     {
> > 969     	swp_entry_t entry;
> > 970     	int n_ret;
> > 971
> > vvv     CID 1492705:  Memory - corruptions  (OVERRUN)
> > vvv     Overrunning struct type swp_entry_t of 8 bytes by passing it to a function which accesses it at byte offset 15.
> > 972     	n_ret = scan_swap_map_slots(si, usage, 1, &entry);
> > 973
> > 974     	if (n_ret)
> > 975     		return swp_offset(entry);
> > 976     	else
> > 977     		return 0;
> >
> > If this is a false positive, please let us know so we can mark it as
> > such, or teach the Coverity rules to be smarter. If not, please make
> > sure fixes get into linux-next. :) For patches fixing this, please
> > include these lines (but double-check the "Fixes" first):
> >
> > Human edit:
> > I can't tell if this is a false positive. The detailed analysis points
> > at:
> >
> > 844        si->cluster_next = offset + 1;
> >    	67. index_const: Pointer slots directly indexed by n_ret++ with value 1.
> > 845        slots[n_ret++] = swp_entry(si->type, offset);
> 
> If my understanding were correct, this will not cause problem.  Because
> in the next line,
> 
>    /* got enough slots or reach max slots? */
>    if ((n_ret == nr) || (offset >= si->highest_bit))
>            goto done;
> 
> The value of n_ret will be checked and function will return if n_ret==1
> because nr==1.

Yeah, agreed. I see that's the only place n_ret is written to. Thanks
for double-checking! I've marked it a false positive.

-- 
Kees Cook