netdev - Re: [PATCH] sctp: Fix error handling for switch statement case in the function sctp_cmd

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: <20160405.192910.1219063056390496976.davem@davemloft.net>
Date:	Tue, 05 Apr 2016 19:29:10 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	daniel@...earbox.net
Cc:	bastienphilbert@...il.com, vyasevich@...il.com,
	nhorman@...driver.com, linux-sctp@...r.kernel.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sctp: Fix error handling for switch statement case in
 the function sctp_cmd_interprete

From: Daniel Borkmann <daniel@...earbox.net>
Date: Tue, 05 Apr 2016 23:53:52 +0200

> On 04/05/2016 11:36 PM, Bastien Philbert wrote:
>> This fixes error handling for the switch statement case
>> SCTP_CMD_SEND_PKT by making the error value of the call
>> to sctp_packet_transmit equal the variable error due to
>> this function being able to fail with a error code. In
> 
> What actual issue have you observed that you fix?
> 
>> addition allow the call to sctp_ootb_pkt_free afterwards
>> to free up the no longer in use sctp packet even if the
>> call to the function sctp_packet_transmit fails in order
>> to avoid a memory leak here for not freeing the sctp
> 
> Not sure how this relates to your code?

Bastien, I'm seeing a clear negative pattern with the bug fixes
you are submitting.

Just now you submitted the ICMP change which obviously was never
tested because it tried to take the RTNL mutex in atomic context,
and now this sctp thing.

If you don't start actually testing your changes and expalining
clearly what the problem actually is, how you discovered it,
and how you actually tested your patch, I will start completely
ignoring your patch submissions.