Stack-based buffer overflow in the PAMBasicAuthenticator::PAMCallback function in OpenPegasus CIM management server (tog-pegasus), when compiled to use PAM and without PEGASUSUSEPAMSTANDALONEPROC defined, might allow remote attackers to execute arbitrary code via unknown vectors, a different vulnerability than CVE-2007-5360.
Heap-based buffer overflow in the LookupMarkMarkPos function in the HarfBuzz module (harfbuzz-gpos.c), as used by Qt before 4.7.4 and Pango, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted font file.
Tavis Ormandy and Julien Tinnes, Google Security Team reported that Kernels <= 2.6.18.8 are vulnerable to a NULL pointer dereference issue when using MSGMORE on udp sockets.
Fixed upstream already by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1e0c14f49d6b393179f423abbac47f85618d3d46
Acknowledgements:
Red Hat would like to thank Tavis Ormandy and Julien Tinnes of the Google Security Team for responsibly reporting this flaw.
Description of problem: Reported by Tavis Ormandy and Julien Tinnes. The SOCKOPSWRAP macro from include/linux/net.h doesn't initialise the sendpage operation in the protoops structure correctly. Leading to a kernel NULL pointer dereference, and thus a local privilege escalation.
Acknowledgements:
Red Hat would like to thank Tavis Ormandy and Julien Tinnes of the Google Security Team for responsibly reporting this flaw.
Multiple race conditions in fs/pipe.c in the Linux kernel before 2.6.32-rc6 allow local users to cause a denial of service (NULL pointer dereference and system crash) or gain privileges by attempting to open an anonymous pipe via a /proc//fd/ pathname.
Daniel Veillard discovered that a specially crafted document can lead to a recursive evaluation of entities, the result being an exhaustion of memory and CPU usage
Acknowledgements:
Red Hat would like to thank Andreas Solberg for responsibly disclosing this issue.
The approxyhttpprocessresponse function in modproxyhttp.c in the modproxy module in the Apache HTTP Server 2.0.63 and 2.2.8 does not limit the number of forwarded interim responses, which allows remote HTTP servers to cause a denial of service (memory consumption) via a large number of interim responses.
Description of problem:
Alexei Dobryanov has reported the following kernel utrace related issue (BZ#245735):
1. late ptracemayattach() check
static int ptraceattach(struct taskstruct task) { ... engine = utraceattach(task, (UTRACEATTACHCREATE | UTRACEATTACHEXCLUSIVE | UTRACEATTACHMATCHOPS), &ptraceutraceops, 0); [error checking] if (ptracemayattach(task)) { [more attaching process]
Doing may attach check there is asking for trouble, because utraceattach() will happily create and modify "struct utrace " and create and attach engines to it on task you don't have permissions. Order should be reverted. That's easy.
2. race around &deadengineops setting...
I originally thought #1 would lead to memory leaks, however, written dumb PTRACEATTACH'er gave much more amazing results.
The following program quickly (1 sec) oopses kernel when run against process you normally can't attach to (like normal user to getty processes)
#include <stdlib.h> #include <sys/ptrace.h>
int main(int argc, char argv[]) { pidt pid = atoi(argv[1]);
while (1) ptrace(PTRACEATTACH, pid, NULL, NULL);
return 0; }
Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<0000000000000000>] [<ffffffff8005f1cd>] reportquiescent+0x36/0x154 [<ffffffff8005f316>] utracequiescent+0x2b/0x238 [<ffffffff800601e9>] utracegetsignal+0x45d/0x4c0 [<ffffffff80039c6f>] getsignaltodeliver+0x169/0x47a [<ffffffff80008f5a>] donotifyresume+0xd0/0x7e2 [<ffffffff80203673>] spinunlockirqrestore+0x3f/0x45 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff801400c0>] ttyread+0x81/0xc7 [<ffffffff80202ede>] tracehardirqsonthunk+0x35/0x37 [<ffffffff80051d71>] tracehardirqson+0x11b/0x13f [<ffffffff80009b43>] sysretsignal+0x21/0x31 [<ffffffff80009deb>] ptregscallcommon+0x67/0xac
This is a race we chatted with Roland about: http://marc.info/?l=linux-kernel&m=117863520707703&w=2
engine's flags and ops settings in utracedetach() and acting on them in reportquiescent():
utracedetach() reportquiescent() --------------- ------------------ [utrace lock held] [utrace lock is not held]
engine->flags = UTRACEEVENT(QUIESCE) | UTRACEACTIONQUIESCE;
if (engine->flags & UTRACEEVENT(QUIESCE)) REPORT(reportquiesce);
rcuassignpointer(engine->ops, &deadengineops);
At the moment of REPORT call engine's ops are still "live" ptrace ops which do not have ->reportquiesce callback. So, there will oops while calling function at NULL address. "Dead" ptrace engine ops do have dummy callback but it wasn't yet glued.
Obviously, patch #1 won't fix this.
3. Looks like nobody filed double free at utrace aka oops at rcuprocesscallbacks() against RHEL5 kernel.
It's bug https://bugzilla.redhat.com/bugzilla/showbug.cgi?id=207002 against FC6, but, hey, every utrace version has it. Test program attached. Every user can trigger it.
The sndseqosssynthmakeinfo function in sound/core/seq/oss/seqosssynth.c in the sound subsystem in the Linux kernel before 2.6.27-rc2 does not verify that the device number is within the range defined by maxsynthdev before returning certain data to the caller, which allows local users to obtain sensitive information.