This issue also affected Red Hat Enterprise Linux 3 through the backport of this functionality. +++ This bug was initially created as a clone of Bug #167703 +++ A flaw has been reported in the ipt_recent module along with a patch http://blog.blackdown.de/static/kernel/ipt_recent-fix.patch A subset of this patch was commited to 2.6 kernel prior to 2.6.12: http://linux.bkbits.net:8080/linux-2.6/cset@42b0f732P_VGfvCBAVpq1Grl7HtA_Q It was originally reported that this flaw can cause a remote crash but in other messages mentioned that this was just on 64-bit systems. The security team haven't yet analysed this flaw to determine the exact consequences or likelyhood of exploitation. The CVE entry states: The ipt_recent kernel module (ipt_recent.c) in Linux kernel before 2.6.12, when running on 64-bit processors such as AMD64, does not properly perform certain time tests when the jiffies value is greater than LONG_MAX, which can allow remote attackers to cause a denial of service (kernel panic) via certain attacks such as SSH brute force.
Mark, I think the crash potential on upstream 2.6 was due to the fact that the variable "hold" was declared as "unsigned long *" but that the buffer was allocated as a set of "u_int32_t" data items (at least in 2.6.11). This allowed an overflow of the buffer in certain cases on 64-bit arches. But in RHEL3, "hold" is declared as "u_int32_t *", which matches the buffer allocation, so I don't think there is any vulnerability there. Do you have a specific report of RHEL3 crashing due to this? If not, and DaveM concurs with my analysis, then I suggest this be closed as NOTABUG.
Thanks, Mark. Correcting state to ASSIGNED. Dave, please check out my analysis in comment #1. If you agree that there is no vulnerability on RHEL3, please close this as NOTABUG. Thanks in advance.
James, you might want to look at this, too.
RHEL3 is not affected by the crash bug, but ipt_recent is mostly non-functional on 64-bit systems, even with the upstream 2.6.x fix applied. The blog.blackdown.de patch is not to be considered seriously, it has many flaws in it, which is why it was not applied upstream. His use of get_seconds() is very error prone, and adds the problem that if you set the time of day to some point in the past, all of his time comparison checks fail. That's why jiffies was being used in this file, so that time always monotonically increases and thus all the time comparisons work out. He's also not handling time overflows properly with his new tests. In short, his patch is buggy. :-) ipt_recent needs to be rewritten from scratch
Thanks, Dave. Closing as NOTABUG.