You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: