Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 234077

Summary: LSPP: ppc 32-bit pread not correctly auditing 4th arg (offset)
Product: Red Hat Enterprise Linux 5 Reporter: Michael C Thompson <thompsmc>
Component: kernelAssignee: Eric Paris <eparis>
Status: CLOSED WONTFIX QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: dzickus, iboverma, sgrubb
Target Milestone: ---   
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard: re
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-03 15:21:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 234654    

Description Michael C Thompson 2007-03-26 21:36:34 UTC
Description of problem:
On ppc64 in 32-bit mode, pread syscall is not audited correctly. The 4th
argument (offset) is consistantly 0.

Version-Release number of selected component (if applicable):
20070208.0

How reproducible:
Always.

Steps to Reproduce:
1. auditctl -a entry,always -F arch=b32 -S pread
2. echo "ABCDEFG" > /tmp/pread_data
3. Compile (gcc -m32) and execute the following:
#include <errno.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

int main()
{
    int fd;
    char buff[5];

    fd = open("/tmp/pread_data",O_RDONLY);
    pread(fd, buff, 5, 1);
    close(fd);
    return 0;
}
4. See audit record's a3 value.
  
Actual results:
type=SYSCALL msg=audit(1174939960.810:64974): arch=14 syscall=179 success=yes
exit=5 a0=3 a1=10020b68 a2=5 a3=0 items=0 ppid=12033 pid=14190 auid=502 uid=503
gid=503 euid=503 suid=0 fsuid=503 egid=503 sgid=0 fsgid=503 tty=pts2
comm="ranges1_test"
exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/filters/ranges1_test"
subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null)


Expected results:
type=SYSCALL msg=audit(1174939960.810:64974): arch=14 syscall=179 success=yes
exit=5 a0=3 a1=10020b68 a2=5 a3=1 items=0 ppid=12033 pid=14190 auid=502 uid=503
gid=503 euid=503 suid=0 fsuid=503 egid=503 sgid=0 fsgid=503 tty=pts2
comm="ranges1_test"
exe="/rhcc/lspp/tests/LTP/ltp-merged/testcases/audit/filters/ranges1_test"
subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null)

Comment 1 George C. Wilson 2007-04-02 20:22:40 UTC
Eric: Looks like not an LSPP blocker. WAD. But just how designed.

Problem is passing a 64-bit offset to 32-bit userspace. Broken into regs 4 & 5,
but only audit 4. Reg 4 is high order of offset.

Comment 3 Steve Grubb 2007-04-03 16:23:43 UTC
This should probably be added to LSPP documentation like the other syscalls that
had minor issues. I think we can close this bz.

Comment 4 Eric Paris 2007-04-03 16:28:11 UTC
There is still some discussion going on about if we should special case this
syscall as I'm told was done apparently for networking and ipc.  Thoughts on the
security relevance of pread and pwrite to collect the offset would be of
interest to see if such work would be useful.

Comment 5 Eric Paris 2007-04-03 17:39:50 UTC
Actualy is this working right on ppc64?  When I just built WITHOUT the -m32 and
I have 2 audit rules

[root@ibm-js20-01 ~]# auditctl -a entry,always -F arch=b64 -S pread
[root@ibm-js20-01 ~]# auditctl -a entry,always -F arch=b32 -S pread

I got

type=SYSCALL msg=audit(1175621755.531:13): arch=14 syscall=179 success=yes
exit=5 a0=3 a1=ffffe8b0 a2=5 a3=0 items=0 pid=2597 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="pread_test" exe="/root/pread_test"

which is most strange to me...

Comment 6 Eric Paris 2007-04-03 17:42:02 UTC
ok, ignore comment #5 for now as it seems the system i'm working isn't even
rhel5 and doesn't even seem to have all the 64 bit libraries installed.   /me
goes to reinstall.

Comment 7 Eric Paris 2007-04-05 19:23:16 UTC
This issue will not be changed for the LSPP kernels as pread/pwrite are not
deemed 'security relevant.'    I'm going to verify my assumptions but for now it
is coming off of the LSPP lists.  I expect this bug to be closed shortly as
"NOTABUG"

Comment 10 RHEL Program Management 2007-05-03 15:21:09 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.