Bug 140085 - LTC9536-bind audit produces wrong audit record.
Summary: LTC9536-bind audit produces wrong audit record.
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Peter Martuccelli
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-19 17:29 UTC by Peter Martuccelli
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-09 20:15:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Peter Martuccelli 2004-11-19 17:29:51 UTC
Hardware Environment:

Software Environment:

Steps to Reproduce:
1. add the following filter entry to /etc/audit/filter.conf:
  syscall bind = always; 
2. reload or stop and start auditd
3. run: aurun nc -l -p 3333 -s

Actual Results:
2004-06-21T20:11:02      9    853     root bind("[sock:af=2,type=1]", 
[TRUNCATED SOCKADDR: len=0], 16); result=0
Expected Results:
2004-06-21T20:12:17      7   1565     root bind("[sock:af=2,type=1]",, 16); result=0

Additional Information:
Glen, please mirror this bug to Red Hat.

Created an attachment (id=5057)
fix off-by-one that causes wrong argument to be decoded

backported bugfix from 2.6 LAuS code, the original code incorrectly
decoded the
wrong argument for T_opaque pointers.

Created an attachment (id=5058)
patch tlo "laus" source code (liblaussrv) to print port numbers properly

After the kernel fix (see previous patch), the syscall is audited
properly, but
the tools don't print it correctly; there is no separator printed
between the
address and the port number:

   root bind("[sock:af=2,type=1]",, 16); result=0

The attached patch to the "laus" package adds a colon before the port

   root bind("[sock:af=2,type=1]",, 16); result=0

Created an attachment (id=5059)
fix for 32bit socketcall audit on 64bit platforms

the socketcall decoding logic assumed that the userspace sizeof(long)
is equal
to the kernel's sizeof(long), which is wrong in the case of 32bit programs
running on a 64bit architecture. 

The attached patch keeps the behavior unchanged for 32/32 or 64/64
but adds a workaround for 32bit code running on 64bit kernels.
Action by: Glen Johnson
Issue Registered
Action by: Glen Johnson

Status set to: Waiting on Tech
File uploaded: audit-bind-kernel.diff

Action by: Glen Johnson

File uploaded: audit-bind-liblaussrv.diff

Action by: Glen Johnson

File uploaded: audit-opteron-bind32.diff

Action by: Glen Johnson
----- Additional Comments From spwoods@us.ibm.com  2004-06-21 20:19

Action by: Glen Johnson
----- Additional Comments From khoa@us.ibm.com  2004-06-22 13:17 -------
We'll close this bug report once Red Hat has fixed this in an official

Action by: Glen Johnson
----- Additional Comments From khoa@us.ibm.com  2004-06-22 13:56 -------
*** Bug 9279 has been marked as a duplicate of this bug. *** 

Action by: bjohnson
Mike, This one been around awhile....any update ?  I've asked peterm
to take a look.

Category set to: Applications

Action by: mgahagan
Peterm is waiting for this one, patches attached.

Issue escalated to Support Engineering Group by: mgahagan.
mgahagan assigned to issue for IBM-LTC.

Action by: jantill

Issue escalated to Sustaining Engineering by: jantill.
jantill assigned to issue for Support Engineering Group.

Action by: jneedle
If Peter wants it, Peter certainly may have it.  Assigning to him.

peterm assigned to issue for Sustaining Engineering.

Action by: peterm
Escalated to Bugzilla

Comment 1 Peter Martuccelli 2004-11-23 18:41:18 UTC
This issue was fixed during the EAL3 certification process, it is
fixed in U4.

Comment 5 Ernie Petrides 2005-09-09 20:11:41 UTC
A fix for this problem was committed to the RHEL3 U3 patch pool
on 25-Jun-2005 (in kernel version 2.4.21-15.18.EL).

Comment 6 Ernie Petrides 2005-09-09 20:15:24 UTC
This problem was fixed in U3 (advisory RHBA-2004:433-17),
although obviously the latest released kernel should be
used (which is 2.4.21-32.0.1.EL, advisory RHSA-2005:472).

Note You need to log in before you can comment on or make changes to this bug.