netdev - Re: [PATCH]: [SCTP]: Fix a race between module load and protosw access

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: <20080320.151854.41734345.davem@davemloft.net>
Date:	Thu, 20 Mar 2008 15:18:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	vladislav.yasevich@...com
Cc:	netdev@...r.kernel.org, lksctp-developers@...ts.sourceforge.net
Subject: Re: [PATCH]: [SCTP]: Fix a race between module load and protosw
 access

From: Vlad Yasevich <vladislav.yasevich@...com>
Date: Thu, 20 Mar 2008 09:30:52 -0400

> There is a race is SCTP between the loading of the module
> and the access by the socket layer to the protocol functions.
> In particular, a list of addresss that SCTP maintains is
> not initialized prior to the registration with the protosw.
> Thus it is possible for a user application to gain access
> to SCTP functions before everything has been initialized.
> The problem shows up as odd crashes during connection
> initializtion when we try to access the SCTP address list.
> 
> The solution is to refactor how we do registration and
> initialize the lists prior to registering with the protosw.
> Care must be taken since the address list initialization
> depends on some other pieces of SCTP initialization.  Also
> the clean-up in case of failure now also needs to be refactored.
> 
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@...com>
> Acked-by: Sridhar Samudrala <sri@...ibm.com>

Looks good, applied, thanks Vlad.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html