Bug 577711 (CVE-2010-1188)

Summary: CVE-2010-1188 kernel: ipv6: skb is unexpectedly freed
Product: [Other] Security Response Reporter: Eugene Teo (Security Response) <eteo>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: dhoward, jolsa, klarsen, maurizio.antillon, plyons, rkhan, tao, vgoyal
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-19 09:10:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 546402, 577712, 577713, 577715, 577716, 577717, 577718    
Bug Blocks:    

Description Eugene Teo (Security Response) 2010-03-29 03:29:49 UTC
Description of problem:
The server side sets IPV6_RECVPKTINFO on a listening socket, and the client side just sends a message to the server.  Then the kernel panic occurs on the server.
    
This problem happens because a skb is forcibly freed in tcp_rcv_state_process().
    
When a socket in listening state(TCP_LISTEN) receives a syn packet, then tcp_v6_conn_request() will be called from tcp_rcv_state_process().  If the tcp_v6_conn_request() successfully returns, the skb would be discarded by __kfree_skb().
    
However, in case of a listening socket which was already set IPV6_RECVPKTINFO, an address of the skb will be stored in treq->pktopts and a ref count of the skb will be incremented in tcp_v6_conn_request().  But, even if the skb is still in use, the skb will be freed.  Then someone still using the freed skb will cause the kernel panic.

Upstream commit:
http://git.kernel.org/linus/fb7e2399ec17f1004c0e0ccfd17439f8759ede01

Comment 3 Kirk Larsen 2010-04-09 00:37:29 UTC
Hi,

Does this affect RHEL 5?

Thanks!

Comment 4 Guil Barros 2010-04-13 13:52:24 UTC
Does disabling ipv6 mitigate this vulnerability?

Comment 5 Eugene Teo (Security Response) 2010-04-14 01:39:58 UTC
(In reply to comment #3)
> Hi,
> 
> Does this affect RHEL 5?

Hi Kirk,

We have released an update for Red Hat Enterprise Linux 5. https://rhn.redhat.com/errata/RHSA-2010-0178.html.

Thanks, Eugene

Comment 6 Eugene Teo (Security Response) 2010-04-14 01:40:26 UTC
(In reply to comment #4)
> Does disabling ipv6 mitigate this vulnerability?    

Yes.

Comment 7 errata-xmlrpc 2010-04-27 12:46:07 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.4.Z - Server Only

Via RHSA-2010:0380 https://rhn.redhat.com/errata/RHSA-2010-0380.html

Comment 8 errata-xmlrpc 2010-05-05 13:05:16 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2010:0394 https://rhn.redhat.com/errata/RHSA-2010-0394.html

Comment 9 errata-xmlrpc 2010-05-18 22:06:19 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4.7 Z Stream

Via RHSA-2010:0424 https://rhn.redhat.com/errata/RHSA-2010-0424.html

Comment 10 errata-xmlrpc 2010-05-25 15:30:03 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.3.Z - Server Only

Via RHSA-2010:0439 https://rhn.redhat.com/errata/RHSA-2010-0439.html

Comment 12 errata-xmlrpc 2010-11-12 09:37:21 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 3 Extended Lifecycle Support

Via RHSA-2010:0882 https://rhn.redhat.com/errata/RHSA-2010-0882.html