+++ This bug was initially created as a clone of Bug #165560 +++
When a user specified IPSEC rule to compile is given, we don't check
the bounds of the direction, leading to overflows of the in-socket
IPSEC rule array. This could allow a local unprivileged user to cause memory
Fixed upstream here on 20050726
See the following threads for a test program and more desciprtion
Note that a fix for this is already committed for RHEL4 U2 in
This doesn't affect 2.4 upstream however RHEL3 contains this functionality as a
backport in linux-2.4.21-ipsec.patch
Mark, please correct the first link in the initial comment. That
one refers to some unrelated upstream change. Thanks in advance.
I believe you mean
Something strangely filtered the -
John, do you have any time to look at this? DaveM says he can't address it
until the end of next week, and we're considering a U6 respin before then.
Mark, do you have any information on how to reproduce this problem?
The patch seems obvious enough. I have test kernels available here:
Is anyone in a position to test against an exploit?
Ernie, how soon do you need this for a respin?
John, Mark is not in a position to test kernel fixes. So you'd need to
recreate the problem from the info available and then verify that the fix
addresses the problem.
We're considering a mid-week target for the U6 respin, which means it would
be desirable to have all relevant patches posted by end-of-day tomorrow.
Reverting to ASSIGNED state. Fix is on target for next RHEL3 U6 respin.
A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-35.EL).
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.