Where
AND
-Infinity
0
Severity
7.8
Input Validation
AV:L/AC:L/Au:N/C:C/I:C/A:C

Description of problem: The handling functions for sending and receiving messages, in rdspagecopyuser(), use the unchecked copyuserinatomic functions without any access checks on user-provided pointers. As a result, by passing a kernel address as an iovec base address in recvmsg-style calls, a local user can overwrite arbitrary kernel memory, which can easily be used to escalate privileges to root.

Introduced via 7875e18e (v2.6.30-rc1).

Acknowledgements:

Red Hat would like to thank Dan Rosenberg of Virtual Security Research for reporting this issue.

1 / 5
Source: Red Hat
First published (updated )
Severity
9.8
AV:N/AC:L/Au:N/C:P/I:P/A:P

Unspecified vulnerability in the Java Runtime Environment (JRE) in Java SE component allows remote attackers to affect confidentiality, integrity, and availability via Unknown vectors.

1 / 2
Source: CISA
First published (updated )
Severity
4.9
Input Validation
AV:L/AC:L/Au:N/C:N/I:N/A:C

Description of problem: The vmxsetmsr function in arch/x86/kvm/vmx.c in the VMX implementation in the KVM subsystem in the Linux kernel before 2.6.29.1 on the i386 platform allows guest OS users to cause a denial of service (OOPS) by setting the EFERLME (aka "Long mode enable") bit in the Extended Feature Enable Register (EFER) model-specific register, which is specific to the x8664 platform.

Reference: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiffplain;h=16175a796d061833aacfbd9672235f2d2725df65

1 / 2
Source: Red Hat
First published (updated )
Severity
4.9
AV:L/AC:L/Au:N/C:N/I:C/A:N

nfsd in the Linux kernel before 2.6.28.9 does not drop the CAPMKNOD capability before handling a user request in a thread, which allows local users to create device nodes, as demonstrated on a filesystem that has been exported with the rootsquash option.

First published (updated )
Severity
9.8
AV:N/AC:M/Au:N/C:N/I:P/A:P

Marsh Ray of PhoneFactor has discovered a flaw in the TLS/SSL protocol related to the handling of the session rehandshakes / renegotiations. This flaw can possibly be used in the MITM attacks and allowing an attacker to inject attacker-chosen plain text prefix to the session of the victim.

Further details are available in the "Authentication Gap in TLS Renegotiation" blog post: http://extendedsubset.com/?p=8

1 / 3
Source: Red Hat
First published (updated )
Severity
9.8
Path Traversal
AV:N/AC:L/Au:N/C:P/I:P/A:P

Multiple directory traversal vulnerabilities in Lintian 1.23.x through 1.23.28, 1.24.x through 1.24.2.1, and 2.x before 2.3.2 allow remote attackers to overwrite arbitrary files or obtain sensitive information via vectors involving (1) control field names, (2) control field values, and (3) control files of patch systems.

First published (updated )
Severity
9.3
Buffer Overflow
AV:N/AC:M/Au:N/C:C/I:C/A:C

Heap-based buffer overflow in the GIFLZWDecompressor::GIFLZWDecompressor function in filter.vcl/lgif/decode.cxx in OpenOffice.org (OOo) before 3.2 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted GIF file, related to LZW decompression.

1 / 2
Source: Red Hat
First published (updated )
Severity
9.3
Integer Overflow, Buffer Overflow
AV:N/AC:M/Au:N/C:C/I:C/A:C

Integer overflow in the XPMReader::ReadXPM function in filter.vcl/ixpm/svtxpmread.cxx in OpenOffice.org (OOo) before 3.2 allows remote attackers to execute arbitrary code via a crafted XPM file that triggers a heap-based buffer overflow.

1 / 2
Source: Red Hat
First published (updated )
Severity
4.9
AV:L/AC:L/Au:N/C:N/I:N/A:C

The futexlockpi function in kernel/futex.c in the Linux kernel before 2.6.33-rc7 does not properly manage a certain reference count, which allows local users to cause a denial of service (OOPS) via vectors involving an unmount of an ext3 filesystem.

First published (updated )
Severity
6.5
Use After Free
AV:N/AC:L/Au:S/C:N/I:N/A:P

Use-after-free vulnerability in kadmin/server/serverstubs.c in kadmind in MIT Kerberos 5 (aka krb5) 1.5 through 1.6.3 allows remote authenticated users to cause a denial of service (daemon crash) via a request from a kadmin client that sends an invalid API version number.

First published (updated )
Severity
9.3
AV:N/AC:M/Au:N/C:C/I:C/A:C

Marc Schoenefeld found a flaw in the way OpenOffice.org 3.2.0 and earlier, enforced non-executable permission, when browsing macros, written in Python scripting language. If a local user was tricked into opening a specially-crafted OpenDocument Text (ODT) file, containing macros, and previewed the macro directories structure, it could lead to Python macro execution even when macros execution was disabled.

1 / 2
Source: Red Hat
First published (updated )
Severity
4.3
AV:N/AC:M/Au:N/C:N/I:N/A:P

The pngdecompresschunk function in pngrutil.c in libpng 1.0.x before 1.0.53, 1.2.x before 1.2.43, and 1.4.x before 1.4.1 does not properly handle compressed ancillary-chunk data that has a disproportionately large uncompressed representation, which allows remote attackers to cause a denial of service (memory and CPU consumption, and application hang) via a crafted PNG file, as demonstrated by use of the deflate compression method on data composed of many occurrences of the same character, related to a "decompression bomb" attack.

First published (updated )
Severity
4.9
AV:L/AC:L/Au:N/C:N/I:N/A:C

Description of problem: A problem was found in the drivers/connector/connector.c code where users could send/allocate arbitrary amounts of NETLINKCONNECTOR messages to the kernel, causing OOM condition, killing selected processes or halting the system.

This is fixed in mainline commit f98bfbd78c37c5946cc53089da32a5f741efdeb7 by removing the code.

commit f98bfbd78c37c5946cc53089da32a5f741efdeb7 Author: Evgeniy Polyakov <zbr> Date: Tue Feb 2 15:58:48 2010 -0800

connector: Delete buggy notification code.

On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh) wrote: > > There are at least two ways to fix it: using a big cannon and a small > > one. The former way is to disable notification registration, since it is > > not used by anyone at all. Second way is to check whether calling > > process is root and its destination group is -1 (kind of priveledged > > one) before command is dispatched to workqueue. > > Well if no one is using it, removing it makes the most sense, right? > > No objection from me, care to make up a patch either way for this?

Getting it is not used, let's drop support for notifications about (un)registered events from connector. Another option was to check credentials on receiving, but we can always restore it without bugs if needed, but genetlink has a wider code base and none complained, that userspace can not get notification when some other clients were (un)registered.

Kudos for Sebastian Krahmer <krahmer>, who found a bug in the code.

Signed-off-by: Evgeniy Polyakov <zbr> Acked-by: Greg Kroah-Hartman <gregkh> Signed-off-by: David S. Miller <davem>

Acknowledgements:

Red Hat would like to thank Sebastian Krahmer for reporting this issue.

1 / 2
Source: Red Hat
First published (updated )
Severity
6.8
Null Pointer Dereference
AV:N/AC:L/Au:S/C:N/I:N/A:C

The kgacceptkrb5 function in krb5/acceptseccontext.c in the GSS-API library in MIT Kerberos 5 (aka krb5) through 1.7.1 and 1.8 before 1.8.2, as used in kadmind and other applications, does not properly check for invalid GSS-API tokens, which allows remote authenticated users to cause a denial of service (NULL pointer dereference and daemon crash) via an AP-REQ message in which the authenticator's checksum field is missing.

First published (updated )
Severity
4.7
AV:L/AC:M/Au:N/C:N/I:N/A:C

Description of problem: The problem seams to be located in fs/binfmtelf.c:loadelfbinary(). It calls SETPERSONALITY() prior checking that the ELF interpreter is available. This in turn makes the previously 32 bit process a 64 bit one which would be fine if execve() would succeed. But after the SETPERSONALITY() the openexec() call fails (because it cannot find the interpreter) and execve() almost instantly returns with an error. If you now look at /proc/PID/maps you'll see, that it has the vsyscall page mapped which shouldn't be. But the process is not dead yet, it's still running. By now generating a segmentation fault and in turn trying to generate a core dump the kernel just dies.

Steps to Reproduce: 1. Enable core dumps 2. Start an 32 bit program that tries to execve() an 64 bit program 3. The 64 bit program cannot be started by the kernel because it can't find the interpreter, i.e. execve returns with an error 4. Generate a segmentation fault 5. panic

(EDIT: This is triggerable on 2.6.31.9-174.fc12.x8664).

Upstream commit: http://git.kernel.org/linus/221af7f87b97431e3ee21ce4b0e77d5411cf1549

Discussions: http://marc.info/?t=126466700200002&r=1&w=2

Acknowledgements:

Red Hat would like to thank Mathias Krause for reporting this issue.

1 / 2
Source: Red Hat
First published (updated )
Severity
7.5
Use After Free
AV:N/AC:M/Au:N/C:N/I:N/A:P

Description of problem: CVE-2009-3553 (bug #530111) has not been completely fixed.

Version-Release number of selected component (if applicable): Versions known to be affected:

cups-1.3.7-11.el54.5 (RHEL-5.4.z) cups-1.3.7-16.el5 (RHEL-5)

Additional info: The cause is that the cupsdDoSelect() function uses one of several implementations depending on the underlying select/poll capabilities of the operating system. For kqueue and epoll implementations, cupsdRemoveSelect() does not immediately decrease the reference count for the file descriptor and instead adds it to the cupsdinactivefds array. File descriptors in that array are finally dereferenced in cupsdStopSelect() (i.e. program termination).

In Red Hat Enterprise Linux, the epoll implementation is used.

The previous fix for CVE-2009-3553 was to check that another reference was held for the file descriptor before calling the writecb function; however, that will always be the case for both the epoll and kqueue implementations.

The correct fix is to check whether the file descriptor is in the cupsdinactivefds array before calling the writecb function.

1 / 2
Source: Red Hat
First published (updated )
Severity
10
AV:N/AC:L/Au:N/C:C/I:C/A:C

The browser engine in Mozilla Firefox 3.0.x before 3.0.18 and 3.5.x before 3.5.8, Thunderbird before 3.0.2, and SeaMonkey before 2.0.3 allows remote attackers to cause a denial of service (memory corruption and application crash) or possibly execute arbitrary code via vectors related to the nsBlockFrame::StealFrame function in layout/generic/nsBlockFrame.cpp, and unspecified other vectors.

First published (updated )
Severity
9.3
Command Injection
AV:N/AC:M/Au:N/C:C/I:C/A:C

OpenOffice.org (OOo) 2.0.4, 2.4.1, and 3.1.1 does not properly enforce Visual Basic for Applications (VBA) macro security settings, which allows remote attackers to run arbitrary macros via a crafted document.

First published (updated )
Severity
9.3
Integer Underflow, Buffer Overflow
AV:N/AC:M/Au:N/C:C/I:C/A:C

An integer underflow flaw, possibly leading to a heap-based buffer overflow, was found in the way OpenOffice.org parsed certain records in Microsoft Word documents. An attacker could create a specially-crafted Microsoft Word document, which once opened by a local, unsuspecting user, could cause OpenOffice.org to crash or, potentially, execute arbitrary code with the permissions of the user running OpenOffice.org.

Credit: Nicolas Joly of VUPEN Vulnerability Research Team

1 / 2
Source: Red Hat
First published (updated )
Severity
9.3
Code Injection, Buffer Overflow
AV:N/AC:M/Au:N/C:C/I:C/A:C

A boundary error flaw, possibly leading to a heap-based buffer overflow, was found in the way OpenOffice.org parsed certain records in Microsoft Word documents. An attacker could create a specially-crafted Microsoft Word document, which once opened by a local, unsuspecting user, could cause OpenOffice.org to crash or, potentially, execute arbitrary code with the permissions of the user running OpenOffice.org.

Credit: Nicolas Joly of VUPEN Vulnerability Research Team

1 / 2
Source: Red Hat
First published (updated )
Severity
5
AV:N/AC:L/Au:N/C:N/I:N/A:P

XMLScanner.java in Apache Xerces2 Java, as used in Sun Java Runtime Environment (JRE) in JDK and JRE 6 before Update 15 and JDK and JRE 5.0 before Update 20, and in other products, allows remote attackers to cause a denial of service (infinite loop and application hang) via malformed XML input, as demonstrated by the Codenomicon XML fuzzing framework.

First published (updated )
Severity
5.5
Infoleak
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Description of problem: The XFSIOCFSGETXATTR ioctl allows unprivileged users to read 12 bytes of uninitialized stack memory, because the fsxattr struct declared on the stack in xfsiocfsgetxattr() does not alter (or zero) the 12-byte fsxpad member before copying it back to the user.

http://www.linux.sgi.com/archives/xfs-masters/2010-09/msg00002.html

Acknowledgements:

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

1 / 3
Source: Red Hat
First published (updated )
Severity
7.2
Double Free
AV:L/AC:L/Au:N/C:C/I:C/A:C

Description of problem: There is a bug in sndseqossopen from sound/core/seq/oss/seqossinit.c. So here's the error path for some setup failure:

error: sndseqosswriteqdelete(dp->writeq); sndseqossreadqdelete(dp->readq); sndseqosssynthcleanup(dp); sndseqossmidicleanup(dp); deleteport(dp); deleteseqqueue(dp->queue); kfree(dp);

This looks okay, but actually, deleteport calls portdelete (eventually... this code is tough to follow) which does a freedevinfo on the owner struct seqossdevinfo, here (around ~269 in seqports.c):

if (port->privatefree) port->privatefree(port->privatedata);

because of this (around ~334 in seqossinit.c):

memset(&callback, 0, sizeof(callback)); callback.owner = THISMODULE; callback.privatedata = dp; callback.eventinput = sndseqosseventinput; callback.privatefree = freedevinfo; port.kernel = &callback;

Which does this:

static void freedevinfo(void private) { struct seqossdevinfo dp = (struct seqossdevinfo )private;

if (dp->timer) sndseqosstimerdelete(dp->timer); if (dp->writeq) sndseqosswriteqdelete(dp->writeq);

if (dp->readq) sndseqossreadqdelete(dp->readq); kfree(dp); }

So.....

deleteport(dp); deleteseqqueue(dp->queue); <= Oops, dereferencing released pointer. kfree(dp); <= Oops, double free.

Acknowledgements:

Red Hat would like to thank Tavis Ormandy for reporting this issue.

1 / 3
Source: Red Hat
First published (updated )
Severity
7.2
Buffer Overflow
AV:L/AC:L/Au:N/C:C/I:C/A:C

Buffer overflow in the niugetethtooltcamall function in drivers/net/niu.c in the Linux kernel before 2.6.36-rc4 allows local users to cause a denial of service or possibly have unspecified other impact via the ETHTOOLGRXCLSRLALL ethtool command.

1 / 3
Source: Launchpad
First published (updated )
Severity
2.1
Input Validation
AV:L/AC:L/Au:N/C:N/I:P/A:N

fs/jfs/xattr.c in the Linux kernel before 2.6.35.2 does not properly handle a certain legacy format for storage of extended attributes, which might allow local users by bypass intended xattr namespace restrictions via an "os2." substring at the beginning of a name.

1 / 2
First published (updated )
Severity
4.9
Null Pointer Dereference
AV:L/AC:L/Au:N/C:N/I:N/A:C

Description of problem: BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: [<f7f06dca>] hashbindelete+0x14/0xad [irda] pdpt = 0000000000a57001 pde = 0000000000000000 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/dmi/id/sysvendor Modules linked in: irda crcccitt fuse ip6tREJECT nfconntrackipv6 ip6tablefilter ip6tables ipv6 vmblock vsock vmmemctl vmhgfs uinput pcnet32 ppdev vmxnet microcode parportpc parport mii vmci i2cpiix4 i2ccore mptspi mptscsih mptbase scsitransportspi [last unloaded: scsiwaitscan]

Pid: 2403, comm: a.out Not tainted 2.6.33.6-147.2.4.fc13.i686.PAE #1 440BX Desktop Reference Platform/VMware Virtual Platform EIP: 0060:[<f7f06dca>] EFLAGS: 00010282 CPU: 0 EIP is at hashbindelete+0x14/0xad [irda] EAX: 00000000 EBX: 00000000 ECX: f2f97f4c EDX: f7f084aa ESI: df1b8800 EDI: f7f084aa EBP: eb19bd78 ESP: eb19bd64 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process a.out (pid: 2403, ti=eb19a000 task=f2ed9980 task.ti=eb19a000) Stack: 00000000 00000202 eb0df2c0 df1b8800 df1a6770 eb19bd84 f7f085f5 eb0df2c0 <0> eb19bd90 f7f0861f eb20c400 eb19bda4 f7f0a958 df1b8800 f7f0ebe4 df1a6770 <0> eb19bdb4 c06ef16e f2e21100 00000008 eb19bdbc c06ef1cf eb19bde0 c04d183a Call Trace: [<f7f085f5>] ? iriasdeleteobject+0x1b/0x2c [irda] [<f7f0861f>] ? iriasdeleteobject+0x19/0x1e [irda] [<f7f0a958>] ? irdarelease+0x65/0x127 [irda] [<c06ef16e>] ? sockrelease+0x14/0x59 [<c06ef1cf>] ? sockclose+0x1c/0x20 [<c04d183a>] ? fput+0xea/0x181 [<c04d18e4>] ? fput+0x13/0x15 [<c04cef5f>] ? filpclose+0x51/0x5b [<c043f260>] ? putfilesstruct+0x5f/0xb3 [<c043f2e8>] ? exitfiles+0x34/0x38 [<c0440a1b>] ? doexit+0x200/0x615 [<c044c4c0>] ? dequeuesignal+0xb1/0x120 [<c0440e9b>] ? dogroupexit+0x6b/0x94 [<c044c89d>] ? getsignaltodeliver+0x36e/0x389 [<c0407cd4>] ? dosignal+0x5a/0x6f4 [<c078359d>] ? apictimerinterrupt+0x31/0x38 [<c0455f57>] ? hrtimernanosleep+0x94/0xdc [<c04d7376>] ? pathput+0x15/0x18 [<c047c6a6>] ? auditsyscallexit+0xfa/0x10f [<c040838d>] ? donotifyresume+0x1f/0x79 [<c07831e4>] ? worknotifysig+0x13/0x1b Code: 04 01 74 0b 8b 55 f0 8d 43 0c e8 b8 bf 87 c8 83 c4 0c 5b 5e 5f 5d c3 55 89 e5 57 89 d7 56 53 89 c3 83 ec 08 c7 45 ec 00 00 00 00 <f6> 40 04 01 74 0b 8d 40 0c e8 40 bf 87 c8 89 45 ec 89 de c7 45 EIP: [<f7f06dca>] hashbindelete+0x14/0xad [irda] SS:ESP 0068:eb19bd64 CR2: 0000000000000004 ---[ end trace 8c5fb89ec896b3a8 ]--- Fixing recursive fault but reboot is needed!

Acknowledgements:

Red Hat would like to thank Tavis Ormandy for reporting this issue.

1 / 3
Source: Red Hat
First published (updated )
Severity
6.2
Input Validation
AV:L/AC:H/Au:N/C:C/I:C/A:C

drivers/media/video/v4l2-compat-ioctl32.c in the Video4Linux (V4L) implementation in the Linux kernel before 2.6.36 on 64-bit platforms does not validate the destination of a memory copy operation, which allows local users to write to arbitrary kernel memory locations, and consequently gain privileges, via a VIDIOCSTUNER ioctl call on a /dev/video device, followed by a VIDIOCSMICROCODE ioctl call on this device.

1 / 3
Source: Launchpad
First published (updated )
Severity
7.8
Null Pointer Dereference
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Description of problem: Reported by Taviso Ormandy via the Ubuntu Security Team.

$ gcc keyctl.c -o keyctl -lkeyutils $ ./keyctl [ 213.999221] BUG: unable to handle kernel NULL pointer dereference at 00000034 [ 214.002770] IP: [<c02f0f2a>] keyctlsessiontoparent+0x12a/0x1c0 [ 214.006011] pde = 0fdb0067 pte = 00000000 [ 214.008007] Oops: 0000 [#1] SMP [ 214.008973] last sysfs file: /sys/module/ppdev/initstate [ 214.010466] Modules linked in: binfmtmisc vmblock vsock vmmemctl vmhgfs acpiphp sndens1371 gameport sndac97codec ac97bus sndpcmoss sndmixeross sndpcm sndseqdummy sndseqoss sndseqmidi sndrawmidi sndseqmidievent sndseq sndtimer sndseqdevice ppdev fbcon tileblit font bitblit softcursor snd psmouse serioraw parportpc soundcore sndpagealloc vmci shpchp i2cpiix4 vga16fb vgastate intelagp agpgart lp parport mptspi mptscsih mptbase floppy scsitransportspi vmxnet [ 214.024416] [ 214.024899] Pid: 1772, comm: a.out Not tainted (2.6.32-24-generic #41-Ubuntu) VMware Virtual Platform [ 214.027413] EIP: 0060:[<c02f0f2a>] EFLAGS: 00210046 CPU: 0 [ 214.028927] EIP is at keyctlsessiontoparent+0x12a/0x1c0 [ 214.030419] EAX: d2cde100 EBX: d2cdeb00 ECX: 000003e8 EDX: cfcfc480 [ 214.032132] ESI: cfddb300 EDI: 00000000 EBP: d2c33f94 ESP: d2c33f7c [ 214.033811] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 214.035292] Process a.out (pid: 1772, ti=d2c32000 task=d79bbfc0 task.ti=d2c32000) [ 214.037346] Stack: [ 214.037926] 00000000 000003e8 d2cde700 004370c0 00000012 08048520 d2c33fac c02f22e5 [ 214.040262] <0> 00000004 00000012 00327ff4 08048520 d2c32000 c01033ec 00000012 004370c0 [ 214.042795] <0> 0804852b 00327ff4 08048520 00000001 00000120 0000007b 0000007b 00000000 [ 214.045405] Call Trace: [ 214.046108] [<c02f22e5>] ? syskeyctl+0x65/0x170 [ 214.047434] [<c01033ec>] ? syscallcall+0x7/0xb [ 214.048711] Code: 90 0f 85 77 ff ff ff 8b 7a 08 89 7d ec 3b 78 18 0f 85 68 ff ff ff 3b 7a 18 0f 85 5f ff ff ff 3b 7a 10 0f 85 56 ff ff ff 8b 7d e8 <3b> 4f 34 8d 76 00 0f 85 47 ff ff ff 8b 7d f0 3b 4f 34 0f 85 3b [ 214.056401] EIP: [<c02f0f2a>] keyctlsessiontoparent+0x12a/0x1c0 SS:ESP 0068:d2c33f7c [ 214.058676] CR2: 0000000000000034 [ 214.059605] ---[ end trace cc41d96061101854 ]---

1 / 3
Source: Red Hat
First published (updated )
Severity
2.1
Infoleak
AV:L/AC:L/Au:N/C:P/I:N/A:N

Description of problem: This problem was originally tracked down by Brad Spengler.

When calling wireless ioctls, if a driver does not correctly validate/shrink iwp->length, the resulting copytouser can leak up to 64K of kernel heap contents.

It seems that this is triggerable[1] in 2.6.32 at least on ath5k, but I was not able to track down how. The twisty maze of ioctl handlers stumped me. :) Other drivers I checked did not appear to have any problems, but the potential remains. I'm not sure if this patch is the right approach; it was fixed differently[2] in grsecurity.

[1] http://forums.grsecurity.net/viewtopic.php?f=3&t=2290&start=0 [2] http://grsecurity.net/~spender/wireless-infoleak-fix2.patch

Discussion: http://lkml.org/lkml/2010/8/27/413

1 / 3
Source: Red Hat
First published (updated )
Severity
8.3
AV:A/AC:L/Au:N/C:C/I:C/A:C

Description of problem:

When parsing a peer's supported HMAC authentication options in the sctpauthasocgethmac() function, a malicious peer can craft their HMAC array in such a way as to cause memory corruption (out-of-bounds read followed by use of retrieved out-of-bounds data), which at the very least could cause a denial of service via kernel panic, and possibly worse. It appears this could be triggered remotely when connecting to a malicious peer, or locally by a user acting as both endpoints. In both cases, the "authenable" sysctl must be set in order to trigger the bug.

References: http://marc.info/?l=oss-security&m=128619854321910&w=1 http://marc.info/?l=linux-kernel&m=128596992418814&w=2

1 / 3
Source: Red Hat
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203