Thread (5 messages) 5 messages, 2 authors, 2022-07-03

Re: [PATCH v4] net: rose: fix null-ptr-deref caused by rose_kill_by_neigh

From: Jakub Kicinski <kuba@kernel.org>
Date: 2022-07-02 19:01:17
Also in: linux-hams, lkml

On Sat, 2 Jul 2022 15:23:57 +0800 (GMT+08:00) duoming@zju.edu.cn wrote:
quoted
On Wed, 29 Jun 2022 18:49:41 +0800 Duoming Zhou wrote:  
quoted
When the link layer connection is broken, the rose->neighbour is
set to null. But rose->neighbour could be used by rose_connection()
and rose_release() later, because there is no synchronization among
them. As a result, the null-ptr-deref bugs will happen.

One of the null-ptr-deref bugs is shown below:

    (thread 1)                  |        (thread 2)
                                |  rose_connect
rose_kill_by_neigh              |    lock_sock(sk)
  spin_lock_bh(&rose_list_lock) |    if (!rose->neighbour)
  rose->neighbour = NULL;//(1)  |
                                |    rose->neighbour->use++;//(2)  
  
quoted
 		if (rose->neighbour == neigh) {  
Why is it okay to perform this comparison without the socket lock,
if we need a socket lock to clear it? Looks like rose_kill_by_neigh()
is not guaranteed to clear all the uses of a neighbor.  
I am sorry, the comparision should also be protected with socket lock.
The rose_kill_by_neigh() only clear the neighbor that is passed as
parameter of rose_kill_by_neigh(). 
Don't think that's possible, you'd have to drop the neigh lock every
time.
quoted
quoted
+			sock_hold(s);
+			spin_unlock_bh(&rose_list_lock);
+			lock_sock(s);
 			rose_disconnect(s, ENETUNREACH, ROSE_OUT_OF_ORDER, 0);
 			rose->neighbour->use--;  
What protects the use counter?  
The use coounter is protected by socket lock.
Which one, the neigh object can be shared by multiple sockets, no?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help