diff options
author | Vesa-Matti J Kari <vmkari@cc.helsinki.fi> | 2008-07-23 00:06:13 +0300 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2008-08-01 12:05:35 -0400 |
commit | 1d6c9649e236caa2e93e3647256216e57172b011 (patch) | |
tree | f2ddd51635a3aac71d11e6d6ae4d4dc698c120f5 /kernel/auditfilter.c | |
parent | ee1d315663ee0b494898f813a266d6244b263b4f (diff) | |
download | kernel_samsung_tuna-1d6c9649e236caa2e93e3647256216e57172b011.zip kernel_samsung_tuna-1d6c9649e236caa2e93e3647256216e57172b011.tar.gz kernel_samsung_tuna-1d6c9649e236caa2e93e3647256216e57172b011.tar.bz2 |
kernel/audit.c control character detection is off-by-one
Hello,
According to my understanding there is an off-by-one bug in the
function:
audit_string_contains_control()
in:
kernel/audit.c
Patch is included.
I do not know from how many places the function is called from, but for
example, SELinux Access Vector Cache tries to log untrusted filenames via
call path:
avc_audit()
audit_log_untrustedstring()
audit_log_n_untrustedstring()
audit_string_contains_control()
If audit_string_contains_control() detects control characters, then the
string is hex-encoded. But the hex=0x7f dec=127, DEL-character, is not
detected.
I guess this could have at least some minor security implications, since a
user can create a filename with 0x7f in it, causing logged filename to
possibly look different when someone reads it on the terminal.
Signed-off-by: Vesa-Matti Kari <vmkari@cc.helsinki.fi>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'kernel/auditfilter.c')
0 files changed, 0 insertions, 0 deletions