** Also affects: cachefilesd (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: cachefilesd (Ubuntu Xenial)
Status: New => Invalid
** Changed in: cachefilesd (Ubuntu Bionic)
Status: New => Triaged
** Changed in: cachefilesd (Ubuntu Bionic)
Status: Triaged => In Progress
** Changed in: cachefilesd (Ubuntu Disco)
Status: New => In Progress
** Changed in: cachefilesd (Ubuntu Eoan)
Status: New => In Progress
** Changed in: cachefilesd (Ubuntu Focal)
Status: New => In Progress
** Changed in: cachefilesd (Ubuntu Focal)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: cachefilesd (Ubuntu Eoan)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: cachefilesd (Ubuntu Disco)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: cachefilesd (Ubuntu Bionic)
Assignee: (unassigned) => Dan Streetman (ddstreet)
** Changed in: cachefilesd (Ubuntu Focal)
Importance: Undecided => Low
** Changed in: cachefilesd (Ubuntu Eoan)
Importance: Undecided => Low
** Changed in: cachefilesd (Ubuntu Focal)
Importance: Low => Medium
** Changed in: cachefilesd (Ubuntu Eoan)
Importance: Low => Medium
** Changed in: cachefilesd (Ubuntu Disco)
Importance: Undecided => Medium
** Changed in: cachefilesd (Ubuntu Bionic)
Importance: Undecided => Medium
** Description changed:
[impact]
the build_cull_table() function scans through elements up to
nr_in_ready_table/nr_in_build_table, and performs actions if a match was
found; however the match detection logic simply compares the for loop
index against nr_in_*_table - 1, which underflows when 0, resulting in
incorrect if section being run and then segfaulting.
[test case]
this is difficult to reproduce and it's unclear the specific conditions
that can reproduce it, but it has been reported to happen and review of
the code shows it clearly could happen.
[regression potential]
this simply moves the -1 over to the for loop counter as a +1, so the
most likely regression would be a for loop counter overflow. However
that should not happen as the culltable_size is limited to 4096, and the
for loop counter is unsigned int; so it should be safe from overflow.
Any other regression would likely involve a similar result as the
current bug, a segfault.
+
+ [other info]
+
+ this bug does not exist in Xenial, as the counters there are signed
+ ints, so underflow (from 0) does not happen.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1854054
Title:
nr_in_ready_table and nr_in_build_table can underflow in if statement
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cachefilesd/+bug/1854054/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
