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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 18 Dec 2017 12:22:51 -0500
From:   Sowmini Varadhan <sowmini.varadhan@...cle.com>
To:     David Miller <davem@...emloft.net>
Cc:     santosh.shilimkar@...cle.com, rds-devel@....oracle.com,
        bot+aaf54a8c644d559d34dedcf3126aac68a20c9e63@...kaller.appspotmail.com,
        linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, linux-kernel@...r.kernel.org
Subject: Re: [rds-devel] BUG: unable to handle kernel NULL pointer
 dereference in rds_send_xmit

> From: Santosh Shilimkar <santosh.shilimkar@...cle.com>
> Date: Mon, 18 Dec 2017 08:28:05 -0800
  :
> > Looks like another one tripping on empty transport. Mostly below
> > should
> > address it but we will test it if it does.

that was my first thought, but it cannot be the case here: rds_sendmsg
etc itself would have bombed if that were the case, and the packet
would never have gotten queued.

This is unlike f3069c6d33, where an applications skips the transport
binding (either misses the explicit bind, or gets the wrong transport
due to an implicit bind) before it triggers the setsockopt.

I suspect that the problems is that the conn (and thus c_trans)
have gotten destroyed, but the cp_send_w work got incorrectly 
re-queued. For example, rds_cong_queue_updates() (because the
peer sent a congestion update) can happen in softirq context, 
and would end up requeing work in the middle of rds_conn_destroy, 
after we have assumed that everything is quisced.

On (12/18/17 12:12), David Miller wrote:
> 
> We're seeming to accumulate a lot of checks like this, maybe there
> is a more general way to deal with this problem?

Yeah, I was thinking about this..  let me try to reprodcue this in-house
and get back with a patchset.  

--Sowmini


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ