The propqueue(...) call in timequeue.c does recursion without any limits. Basically, it recursively runs sub-directories.
This means, that theoretically you could create a stack overflow situation if propqueues are sufficiently nested. That said, I think on a modern system, the maximum length of a property name wouldn't be long enough to cause the program to run out of stack space. Still, each 'frame' takes up a little over 2x BUFFER_LENGTH of space and BUFFER_LENGTH is 8k ... so that adds up quickly.
If it is easy enough to do so, I'd like to actually test to see if this is a problem. Regardless, imposing a depth or limit (preferably a tunable one) would be very wise I think. At the very least, it would prevent a bad actor from loading up something with thousands of propqueue items to chug through.
wyld-sw
commented
1 year ago
The propqueue(...) call in timequeue.c does recursion without any limits. Basically, it recursively runs sub-directories.
This means, that theoretically you could create a stack overflow situation if propqueues are sufficiently nested. That said, I think on a modern system, the maximum length of a property name wouldn't be long enough to cause the program to run out of stack space. Still, each 'frame' takes up a little over 2x BUFFER_LENGTH of space and BUFFER_LENGTH is 8k ... so that adds up quickly.
If it is easy enough to do so, I'd like to actually test to see if this is a problem. Regardless, imposing a depth or limit (preferably a tunable one) would be very wise I think. At the very least, it would prevent a bad actor from loading up something with thousands of propqueue items to chug through.