On Thu, Apr 23, 2020 at 01:57:50PM +0800, Huang, Ying wrote: > coverity-bot <keescook@xxxxxxxxxxxx> 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
