New Google ChromeOS updates cause 100% CPU usage, heating issues

Re:New Google ChromeOS updates cause 100% CPU usage, heating... by makecheck on Sunday September 27, 2020 @06:29PM (#24610691)

It’s actually kind of amazing just how small of a problem can cause a high-CPU bug. For example, decrementing an unsigned integer to get to a gazillion when you thought you were near zero. And with 64-bit variables being more common, the wrap-around value is a hell of a lot bigger so you could tee up a ton of extra CPU work from something like this.

I like to add sanity checks to loops that force them to break after some “clearly unreasonable” amount, and other such guards, just in case.

[ Parent | on HN ]

Re:New Google ChromeOS updates cause 100% CPU usage, heating... by SCHiM on Sunday September 27, 2020 @07:03PM (#24610927)

That wrap around is very often even a security vulnerability.

The common usage pattern in low level C is:

  if (attacker_size == 0)
    return SizeError;

  char* string_buffer = malloc(attacker_size+1); // oops, string_buffer could be 0 sized.
  memcpy(string_buffer, attacker_buffer, attacker_size);

This caused huge security issues, 2 separate times. The first time was when attackers started understanding integer overflow attacks. The second time was when codebases switched from 32 to 64 bit. The last one is more tricky. But I have seen code 'ported' (that I think looked) like this:

  uint64_t attacker_size = ...;
  if ( attacker_size == 0 || attacker_size == UINT64_MAX)
    return SizeError;
  uint32_t string_size = ((uint32_t)attacker_size+1)*2; // Oops, overflow on 32 bit register, string_size = 0;
  // etc

[ Parent | on HN ]

Re:New Google ChromeOS updates cause 100% CPU usage, heating... by type0 on Monday September 28, 2020 @05:55AM (#24614909)

> decrementing an unsigned integer to get to a gazillion

only until you reach googol, then it should be fine /s

[ Parent | on HN ]