group.of.nepali.translators team mailing list archive

[Dan Streetman <ddstreet@xxxxxxxxxxxxx>]

** 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 नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1854054

Title:
  nr_in_ready_table and nr_in_build_table can underflow in if statement

Status in cachefilesd package in Ubuntu:
  In Progress
Status in cachefilesd source package in Xenial:
  Invalid
Status in cachefilesd source package in Bionic:
  In Progress
Status in cachefilesd source package in Disco:
  In Progress
Status in cachefilesd source package in Eoan:
  In Progress
Status in cachefilesd source package in Focal:
  In Progress

Bug description:
  [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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cachefilesd/+bug/1854054/+subscriptions