netdev - Re: [RFC] USB: ipeth: race between ipeth

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: <40b8002c-927c-434f-a82c-73443e0207f7@pen.gy>
Date: Thu, 1 Aug 2024 21:42:02 +0200
From: Foster Snowhill <forst@....gy>
To: Oliver Neukum <oneukum@...e.com>
Cc: netdev@...r.kernel.org, linux-usb@...r.kernel.org, gvalkov@...il.com
Subject: Re: [RFC] USB: ipeth: race between ipeth_close and error handling

Hello Oliver,

Thank you for the patch and patience!

> ipheth_sndbulk_callback() can submit carrier_work
> as a part of its error handling. That means that
> the driver must make sure that the work is cancelled
> after it has made sure that no more URB can terminate
> with an error condition.
> 
> Hence the order of actions in ipeth_close() needs
> to be inverted.

The change looks reasonable to me. It's been a while, but do you perhaps
recall how you stumbled upon this? Was that a proactive fix, or was it
in response to an issue you (or someone else) encountered? Basically
wondering if this is something I could test/reproduce.

I'm planning to submit a few patches for ipheth shortly, would it be
alright with you if I included yours in the series as well? If so, I'll
fix ipeth -> ipheth spelling if you don't mind.

Cheers,
Foster