linux-kernel - Re: [PATCH] net/ncsi: Fix NULL pointer derefence if CIS arrives before SP

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] [day] [month] [year] [list]

Message-ID: <Z4g+LmRZC/BXqVbI@home.paul.comp>
Date: Thu, 16 Jan 2025 02:01:02 +0300
From: Paul Fertser <fercerpav@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Eddie James <eajames@...ux.ibm.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, horms@...nel.org, pabeni@...hat.com,
        edumazet@...gle.com, davem@...emloft.net, sam@...dozajonas.com,
        Ivan Mikhaylov <fr0st61te@...il.com>
Subject: Re: [PATCH] net/ncsi: Fix NULL pointer derefence if CIS arrives
 before SP

Hi Jakub,

On Tue, Jan 14, 2025 at 02:49:32PM -0800, Jakub Kicinski wrote:
> Any thoughts on this fix?

This indeed looks related to what we discussed!

> On Fri, 10 Jan 2025 13:41:33 -0600 Eddie James wrote:
> > If a Clear Initial State response packet is received before the
> > Select Package response, then the channel set up will dereference
> > the NULL package pointer. Fix this by setting up the package
> > in the CIS handler if it's not found.

My current notion is that the responses can't normally be re-ordered
(as we are supposed to send the next command only after receiving
response for the previous one) and so any surprising event like that
signifies that the FSM got out of sync (unfortunately it's written in
such a way that it switches to the "next state" based on the quantity
of responses the current state expected, not on the actual content of
them; that's rather fragile).

Sending the "Select Package" command is the first thing that is
performed after package discovery is complete so problems in that area
suggest that the reason might be lack of processing for the response
to the last "Package Deselect" command: receiving it would advance the
state machine prematurely. It's not quite clear to me how the SP
response can be lost altogether or what else happens there in the
failure case, unfortunately it's not reproducible on my system so I
can't just add more debugging to see all responses and state
transitions as they happen.

Eddie, how easy is it to reproduce the issue in your setup? Can you
please try if the change in [0] makes a difference?

[0] https://lore.kernel.org/all/Z4ZewoBHkHyNuXT5@home.paul.comp/

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@...il.com