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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGxU2F5zhfWymY8u0hrKksW8PumXAYz-9_qRmW==92oAx1BX3g@mail.gmail.com>
Date: Wed, 22 Jan 2025 16:47:46 +0100
From: Stefano Garzarella <sgarzare@...hat.com>
To: Michal Luczaj <mhal@...x.co>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	George Zhang <georgezhang@...are.com>, Dmitry Torokhov <dtor@...are.com>, Andy King <acking@...are.com>, 
	netdev@...r.kernel.org
Subject: Re: [PATCH net v2 0/6] vsock: Transport reassignment and error
 handling issues

On Wed, 22 Jan 2025 at 15:16, Michal Luczaj <mhal@...x.co> wrote:
>
> On 1/22/25 12:45, Stefano Garzarella wrote:
> > On Tue, Jan 21, 2025 at 03:44:01PM +0100, Michal Luczaj wrote:
> >> Series deals with two issues:
> >> - socket reference count imbalance due to an unforgiving transport release
> >>  (triggered by transport reassignment);
> >> - unintentional API feature, a failing connect() making the socket
> >>  impossible to use for any subsequent connect() attempts.
> >>
> >> Signed-off-by: Michal Luczaj <mhal@...x.co>
> >> ---
> >> Changes in v2:
> >> - Introduce vsock_connect_fd(), simplify the tests, stick to SOCK_STREAM,
> >>  collect Reviewed-by (Stefano)
> >> - Link to v1: https://lore.kernel.org/r/20250117-vsock-transport-vs-autobind-v1-0-c802c803762d@rbox.co
> >
> > Thanks for sorting out my comments, I've reviewed it all and got it
> > running, it seems to be going well!
>
> Great! I was worried that I might have oversimplified the UAF selftest
> (won't trigger the splat if second transport == NULL), so please let me
> know if it starts acting strangely (quietly passes the test on an unpatched
> system), and for what combination of enabled transports.

Yeah, I was worrying the same and thinking if it's better to add more
connect also with LOOPBACK and a CID > 2 to be sure we test all the
scenarios, but we can do later, for now let's have this series merged
to fix the real issue.

I tested without the fixes (first 2 patches) and I can see the
use-after-free reports only on the "host" where I have both loopback
and H2G loaded, but this should be fine.

Thanks for your work!
Stefano


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ