netdev - BUG? possible race due to the absence of barrier

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 linux-hardening linux-cve-announce 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