5 ms·
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 yo
by makecheck 6y ago
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.
- SCHiM 6y agoThat 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
- deleted 6y ago[deleted]
- type0 6y ago> decrementing an unsigned integer to get to a gazillion only until you reach googol, then it should be fine /s