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
| ||
|
Date: Tue, 10 Jan 2017 16:22:51 +0200 From: Hadar Hen Zion <hadarh@...lanox.com> To: <davem@...emloft.net> CC: <netdev@...r.kernel.org>, <ogerlitz@...lanox.com>, <idosch@...lanox.com> Subject: using rcu_read_lock() after calling dst_neigh_lookup Hi Dave, Drivers which are calling dst_neigh_lookup() are also using rcu_read_lock() before accessing the neigh pointer (and asking it's ll address data and its validity state). You can find the same behavior in: drivers/infiniband/core/addr.c, drivers/infiniband/hw/i40iw/i40iw_cm.c, drivers/infiniband/hw/nes/nes_cm.c, etc. (the above locations are just an example). While the documentation in neighbour.c says: "Neighbour entries are protected: - with reference count. - with rwlock neigh->lock Reference count prevents destruction. neigh->lock mainly serializes ll address data and its validity state." So what is the right way to protect the neigh entry parameters? I couldn't find why rcu_read_lock() is helping here (dst_neigh_lookup already takes a reference on the neigh). Thank you, Hadar
Powered by blists - more mailing lists