Skip to contentSkip to conversation

Coverity: scan_swap_map(): Memory - corruptions

DISCUSSION coverity-bot 2 participants 3 messages Apr 22, 2020 – Apr 23, 2020 Linux-next tree

lore
Share & tools
lore
#0 lore raw

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...

Addresses-Coverity-ID: 1492705 ("Memory - corruptions")

Fixes 36005bae205d ("mm/swap: allocate swap slots in batches")

Thanks for your attention!

Signature · 1 line
Coverity-bot
#1 lore raw
Quoted 36 lines · 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):

Quoted 7 lines

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

author
#2 lore raw
Quoted 49 lines · Ying
Quoted 36 lines · 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):

Quoted 7 lines

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,

Quoted 6 lines
   /* 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.

Signature · 1 line
Kees Cook