lists.openwall.net   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-next>] [day] [month] [year] [list]
Date:	Wed, 13 Jan 2010 13:35:07 +0900
From:	홍신 shin hong <hongshin@...il.com>
To:	netdev@...r.kernel.org
Subject: BUG? possible race due to the absence of barrier

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.
Thank you.

Sincerely
Shin Hong
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists