This fixes a bug in the order of dccp_rcv_state_process() that still permitted reception even after closing the socket. A Reset after close thus causes a NULL pointer dereference by not preventing operations on an already torn-down socket. dccp_v4_do_rcv() | | state other than OPEN v dccp_rcv_state_process() | | DCCP_PKT_RESET v dccp_rcv_reset() | v dccp_time_wait() WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128() Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah [<c0038850>] (unwind_backtrace+0x0/0xec) from [<c0055364>] (warn_slowpath_common) [<c0055364>] (warn_slowpath_common+0x4c/0x64) from [<c0055398>] (warn_slowpath_n) [<c0055398>] (warn_slowpath_null+0x1c/0x24) from [<c02b72d0>] (__inet_twsk_hashd) [<c02b72d0>] (__inet_twsk_hashdance+0x48/0x128) from [<c031caa0>] (dccp_time_wai) [<c031caa0>] (dccp_time_wait+0x40/0xc8) from [<c031c15c>] (dccp_rcv_state_proces) [<c031c15c>] (dccp_rcv_state_process+0x120/0x538) from [<c032609c>] (dccp_v4_do_) [<c032609c>] (dccp_v4_do_rcv+0x11c/0x14c) from [<c0286594>] (release_sock+0xac/0) [<c0286594>] (release_sock+0xac/0x110) from [<c031fd34>] (dccp_close+0x28c/0x380) [<c031fd34>] (dccp_close+0x28c/0x380) from [<c02d9a78>] (inet_release+0x64/0x70) The fix is by testing the socket state first. Receiving a packet in Closed state now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1. Upstream commit: http://git.kernel.org/linus/720dc34bbbe9493c7bd48b2243058b4e447a929d
Statement: This issue did not affect the version of Linux kernel as shipped with Red Hat Enterprise Linux 4 as it did not include support for the DCCP protocol. Future updates in Red Hat Enterprise Linux 5, 6 and Red Hat Enterprise MRG may address this flaw.
Mitigation: For users that do not run applications that use DCCP, you can prevent the dccp module from being loaded by adding the following entry to the end of the /etc/modprobe.d/blacklist file: blacklist dccp This way, the dccp module cannot be loaded accidentally, which may occur if an application that requires DCCP is started. A reboot is not necessary for this change to take effect but do make sure the module is not loaded in the first place. You can verify that by running: lsmod | grep dccp You may also consider removing the CAP_SYS_MODULE capability from the current global capability set to prevent kernel modules from being loaded or unloaded. The CAP_SYS_MODULE has a capability number of 16 (see linux/capability.h). The default value has all the bits set. To remove this capability, you have to clear the 16th bit of the default 32-bit value, e.g. 0xffffff ^ (1 << 16): echo 0xFFFEFFFF > /proc/sys/kernel/cap-bound
Fail to modprobe dccp See:https://bugzilla.redhat.com/show_bug.cgi?id=698062 and dccp: fix bug in cache allocation http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8ed030dd0aa400d18c63861c2c6deb7c38f4edde
This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2011:0500 https://rhn.redhat.com/errata/RHSA-2011-0500.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0498 https://rhn.redhat.com/errata/RHSA-2011-0498.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2011:0833 https://rhn.redhat.com/errata/RHSA-2011-0833.html