Fixed bug GHSA-3qgc-jrrr-25jv (Bypass of CVE-2012-1823, Argument Injection in PHP-CGI). (CVE-2024-4577)

Last updated 24 July 2024

Commit 5b7c84066733c5dfb0e4016d939757b38de189e4 ('ipv4: correct IGMP behavior on v3 query during v2-compatibility mode') added yet another case for query parsing, which can result in maxdelay = 0. Substitute a value of 1, as in the usual v3 case.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654876

code added in 2.6.36-rc8.

Upstream commit: http://git.kernel.org/linus/a8c1f65c79cbbb2f7da782d4c9d15639a9b94b27

Acknowledgements:

Red Hat would like to thank Simon McVittie for reporting this issue.

A flaw was found in the way Linux kernel's floppy driver treated userspace provided data in certain error code path while processing FDRAWCMD ioctl command. An local user with write access to /dev/fdX could use this flaw to kfree() arbitrary data. (CVE-2014-1737)

It was found that Linux kernel's floppy driver leaked internal kernel memory addresses to userspace during processing of FDRAWCMD ioctl command. An local user with write access to /dev/fdX could use this flaw to get information about kernel heap arrangment. (CVE-2014-1738)

An local user with write access to /dev/fdX could use these two flaws (CVE-2014-1737 in combination with CVE-2014-1738) to escalate their privileges on the system.

Acknowledgements:

Red Hat would like to thank Matthew Daley for reporting these issues.

Last updated 24 July 2024

Last updated 24 July 2024

Integer overflow in the agpgenericinsertmemory function in drivers/char/agp/generic.c in the Linux kernel before 2.6.38.5 allows local users to gain privileges or cause a denial of service (system crash) via a crafted AGPIOCBIND agpioctl ioctl call.

In ibuverbspollcq() code there is a potential integer overflow if userspace passes in a large cmd.ne. The calls to kmalloc() would allocate smaller buffers than intended, leading to memory corruption. There iss also an information leak if resp wasn't all used. Unprivileged userspace may call this function, although only if an RDMA device that uses this function is present.

Fix this by copying CQ entries one at a time, which avoids the allocation entirely, and also by moving this copying into a function that makes sure to initialize all memory copied to userspace.

Upstream commit: http://git.kernel.org/linus/7182afea8d1afd432a17c18162cc3fd441d0da93

Last updated 24 July 2024

A malicious user or buggy application can inject code and trigger an infinite loop in inetdiagbcaudit()

Also make sure each instruction is aligned on 4 bytes boundary, to avoid unaligned accesses.

http://thread.gmane.org/gmane.linux.network/197206/focus=197386 http://patchwork.ozlabs.org/patch/100857/

Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

A signedness issue has been found in nextpidmap() function when the "last" parameter is negative as nextpidmap() just quietly accepted whatever "last" pid that was passed in, which is not all that safe when one of the users is /proc.

Setting fpos to negative value when accessing /proc via readdir()/getdents() resulted in sign extension of this value when map pointer was being constructed.

This later lead to #GP becasue the final pointer was not cannonical (x8664).

map = &pidns->pidmap[(last + 1)/BITSPERPAGE]; ffffffff810ac3b4: 48 63 f6 movslq %esi,%rsi <- sign extension (fpos+-) ffffffff810ac3b7: 81 e2 ff 7f 00 00 and $0x7fff,%edx ffffffff810ac3bd: 48 c1 ee 0f shr $0xf,%rsi ffffffff810ac3c1: 48 c1 e6 04 shl $0x4,%rsi ffffffff810ac3c5: 48 8d 5c 37 08 lea 0x8(%rdi,%rsi,1),%rbx ... if (unlikely(!map->page)) ffffffff810ac3cc: 48 8b 7b 08 mov 0x8(%rbx),%rdi <- #GP

Only x8664 architecture seems to be vulnerable to this particular issue (tested ppc64, s390x, ia64).

Reference: http://groups.google.com/group/fa.linux.kernel/browsethread/thread/93c1088451fd3522/4a28ecb7f755a88d?#4a28ecb7f755a88d

Upstream commit: http://git.kernel.org/linus/c78193e9 http://git.kernel.org/linus/d8bdc59f

Acknowledgements:

Red Hat would like to thank Robert Swiecki for reporting this issue.

kernel/signal.c in the Linux kernel before 2.6.39 allows local users to spoof the uid and pid of a signal sender via a sigqueueinfo system call.

Last updated 24 July 2024

Last updated 24 July 2024

A flaw was found in the way the Linux kernel's floppy driver handled user space provided data in certain error code paths while processing FDRAWCMD IOCTL commands. A local user with write access to /dev/fdX could use this flaw to free (using the kfree() function) arbitrary kernel memory. (CVE-2014-1737, Important) It was found that the Linux kernel's floppy driver leaked internal kernel memory addresses to user space during the processing of the FDRAWCMD IOCTL command. A local user with write access to /dev/fdX could use this flaw to obtain information about the kernel heap arrangement. (CVE-2014-1738, Low) Note: A local user with write access to /dev/fdX could use these two flaws (CVE-2014-1737 in combination with CVE-2014-1738) to escalate their privileges on the system.

Last updated 24 July 2024