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 following shows the relevant code. When the SOCK_TIMESTAMP flag is not set in possibly already allocated and in-use objects, this function will set it thus corrupting the object. This leads to terrible instability :-/
int sock_get_timestampns(struct sock *sk, struct timespec __user *userstamp)
{
struct timespec ts;
if (!sock_flag(sk, SOCK_TIMESTAMP))
sock_enable_timestamp(sk, SOCK_TIMESTAMP);
I've tried to come up with an alternative solution but was not successful. Care should be taken to only execute this ioctl against sockets that have a high probability of being ones we control.
The text was updated successfully, but these errors were encountered:
KEEN TEAM @k33nteam Sep 15 @jduck @fi01_IS01 and yes, the probe may cause some issue if other obj comes in, but anyway better chance than random pick :-P
The following shows the relevant code. When the SOCK_TIMESTAMP flag is not set in possibly already allocated and in-use objects, this function will set it thus corrupting the object. This leads to terrible instability :-/
I've tried to come up with an alternative solution but was not successful. Care should be taken to only execute this ioctl against sockets that have a high probability of being ones we control.
The text was updated successfully, but these errors were encountered: