Continuation of D9903.

[kib]

Summary

Make set_/__throw_constraint_handler_s thread-safe.
Move __throw prototype into libc_private.h.
Minor style editings.

[trix_juniper.net]

lib/libc/stdlib/set_constraint_handler_s.c

59

A memory leak, need to free old.

[kib]

lib/libc/stdlib/set_constraint_handler_s.c

59

Well, I cannot free the memory there, see the updated comment above the definition of '_ch'. If going into this direction, either memory should not be allocated (could you, please, point to the rationale text ?) or lock used instead of lockless algorithm.

I thought that the set interface is used rarely so that the leak is not important.

[kib]

Use lock and free old handler pointer.

Still, I would like to see a reference to the recommendation to malloc() the pointer memory.

[trix_juniper.net]

lib/libc/stdlib/set_constraint_handler_s.c

59

Instead of atomics, a mutex would work.
Here is the rationale from n1173

Most implementations will probably use a pointer to function in their implementation of the set_constraint_handler_s function to hold the address of the currently
registered handler. Unfortunately, pointers to functions are employed by many security exploits. If an exploit deposits new code into a program, the exploit must find a way to cause that new code to be executed. The most common way is to alter the return address on the stack to point to the new code, but an alternative is to find a pointer to a function, and store the address of the new code in that pointer.
The committee thought that the benefit of a user-settable runtime-constraint handler
justified providing another pointer to function that might be exploited. There are steps that an implementation can take to mitigate the vulnerability of the pointer. Some
possibilities are:
• Dynamically allocate the pointer or otherwise arrange for the address of the
pointer to change every time the program runs
• Write-protect the page containing the pointer, and have
set_constraint_handler_s only write-enable the storage when it is
updating the pointer’s value.
• “Encode” the value of the pointer, so that it is not a pure address.

[emaste]

Committed in rS316213

[emaste]

@kib can you close this?