lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 13 Jan 2010 09:24:01 +0000
From:	Jarek Poplawski <>
To:	=?ISO-8859-2?Q?=3F=3F_shin_hong?= 
Subject: Re: BUG? possible race due to the absence of barrier

On 13-01-2010 05:35, ?? shin hong wrote:
> Hi. I am reporting a type of suspected bugs due to
> the lack of enforcing operation order by memory barrier.
> I found this issue while I read the code, so that
> it might not be real. But, please examine this issue.
> We often allocate an object, initialize it, and then link it to a data
> structure.
> Then any thread can access the object.
> For this pattern of programming, it seems to be necessary that
> memory barrier should confirm that the initializations and the linking
> to global data structures are not disordered by CPU or compilers.
> atm_add_addr() in /net/atm/addr.c has the following code:
>  88   this = kmalloc(sizeof(struct atm_dev_addr), GFP_ATOMIC);
>  89   if (!this) {
>  90     spin_unlock_irqrestore(&dev->lock, flags);
>  91     return -ENOMEM;
>  92   }
>  93   this->addr = *addr;
>  94   list_add(&this->entry, head);
> The operation at line 93 might be executed earlier than that of line 94.
> Then, the other thread might read uninitialized value of this
> if there is other concurrent thread which iterates the list.
> Please examine this issue and let me know your opinions.

Should be safe under the spin_lock() (and its barriers).

Jarek P.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists