Bug 502473 - Failure logging execve with lots of arguments
Failure logging execve with lots of arguments
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: rc
: ---
Assigned To: Cong Wang
Petr Beňas
Depends On:
Blocks: 509134
  Show dependency treegraph
Reported: 2009-05-25 08:17 EDT by Matthew Booth
Modified: 2015-01-04 17:58 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 509134 (view as bug list)
Last Closed: 2011-02-16 10:56:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
GDB session showing message received->return EBADE (2.91 KB, text/plain)
2009-05-25 08:17 EDT, Matthew Booth
no flags Details
fix message length accounting (673 bytes, patch)
2009-05-26 19:06 EDT, Eric Paris
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0263 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 4.9 kernel security and bug fix update 2011-02-16 10:14:55 EST

  None (edit)
Description Matthew Booth 2009-05-25 08:17:28 EDT
Created attachment 345304 [details]
GDB session showing message received->return EBADE

Description of problem:
Execute the following command:

seq 1 1000 | xargs echo

In the output, you get a single EXECVE record, which start with this:

type=EXECVE msg=audit(1243248052.942:49):  a857="857" a858="858"

The first 857 arguments have been lost.

The kernel is, however, emitting the preceding record. I've attached some gdb output which shows the problem. Here's a snippet:

102     len = recvfrom(fd, &rep->msg, sizeof(rep->msg), block|peek,
(gdb) n
105     if (len < 0) {
(gdb) print rep->msg
$4 = {nlh = {nlmsg_len = 9246, nlmsg_type = 1309, nlmsg_flags = 0,
    nlmsg_seq = 0, nlmsg_pid = 0},
  data = "audit(1243249450.436:190): argc=1001 a0=\"echo\" a1=\"1\" a2=\"2\" a3=\"3\" a4=\"4\" a5=\"5\" a6=\"6\" a7=\"7\" a8=\"8\" a9=\"9\" a10=\"10\" a11=\"11\" a12=\"12\" a13=\"13\" a14=\"14\" a15=\"15\" a16=\"16\" a17=\"17\" a18=\"18\" a19=\"19\" "...}
(gdb) print len
$5 = 8476

I don't understand why only 8476 bytes have been returned, as sizeof(rep->msg) is 8970 bytes + sizeof(struct nlmsghdr). However, it appears that this is incomplete, which later results in EBADE being returned.

This bug results in a predictable omission of data from the audit record.

Version-Release number of selected component (if applicable):
Comment 1 Steve Grubb 2009-05-26 12:00:03 EDT
Looking at the gdb output, libaudit tells the kernel how big its buffer is. The kernels sends the record. Libaudit checks a few things and then calls the NLMSG_OK macro. The record fails this test, so I would also lean towards this being a kernel bug.

Also, the RHEL4 user space implementation is not expecting split execve records.
Comment 2 Eric Paris 2009-05-26 19:05:30 EDT
RHEL4 userspace has the choice of accepting split records or of handling records larger than 8k since RHEL4 can handle execve arguments >8k (always has been able to)

Anyway the problem appears to be in my accounting of how much information I had sent to userspace.  I forgot to account for the fact that strings are surrounded by ""  Thus in this case when jamming 800+ arguments into one message my accounting was off by 800*2 bytes.

Simple enough patch to fix my estimates.
Comment 3 Eric Paris 2009-05-26 19:06:10 EDT
Created attachment 345543 [details]
fix message length accounting
Comment 5 RHEL Product and Program Management 2009-07-02 17:43:49 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 6 Vivek Goyal 2009-07-28 13:22:39 EDT
Committed in 89.7.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 10 Petr Beňas 2010-11-23 07:05:07 EST
Reproduced in 89.6.EL and verified in 89.7.EL.
Comment 12 errata-xmlrpc 2011-02-16 10:56:41 EST
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 therefore 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.


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