Accessibility. A privacy issue was addressed with improved private data redaction for log entries.

In libxml2 before 2.10.4, parsing of certain invalid XSD schemas can lead to a NULL pointer dereference and subsequently a segfault. This occurs in xmlSchemaFixupComplexType in xmlschemas.c.

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btintel: Fix null ptr deref in btintelreadversion

If hcicmdsynccomplete() is triggered and skb is NULL, then hdev->reqskb is NULL, which will cause this issue.

In the Linux kernel, the following vulnerability has been resolved:

ACPI: LPIT: Avoid u32 multiplication overflow

In lpitupdateresidency() there is a possibility of overflow in multiplication, if tsckhz is large enough (> UINTMAX/1000).

Change multiplication to mulu32u32().

Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: l2cap: fix null-ptr-deref in l2capchantimeout

The Linux kernel CVE team has assigned CVE-2024-27399 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051300-CVE-2024-27399-afa8@gregkh/T

Fixed bug (Use-after-free in exif parsing under memory sanitizer). (CVE-2019-11050)

Fixed bug (Buffer underflow in bcshiftaddsub). (CVE-2019-11046)

A vulnerability was found in PHP versions 7.2.x below 7.2.26, 7.3.x below 7.3.13 and 7.4.0, PHP DirectoryIterator class accepts filenames with embedded \0 byte and treats them as terminating at that byte. This could lead to security vulnerabilities, e.g. in applications checking paths that the code is allowed to access.

Reference: https://bugs.php.net/bug.php?id=78863

drm/amdgpu: Fix possible NULL dereference in amdgpurasqueryerrorstatushelper()

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix deadlock or deadcode of misusing dget()

The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first.

But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.

In the Linux kernel, the following vulnerability has been resolved:

rpmsg: virtio: Free driveroverride when rpmsgremove()

Free driveroverride when rpmsgremove(), otherwise the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsgns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] kmemcacheallocnode+0x1f8/0x320 [<000000002300d89b>] kmallocnodetrackcaller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driversetoverride+0xd0/0x164 [<000000003e9c4ea5>] rpmsgregisterdeviceoverride+0x98/0x170 [<000000001c0c89a8>] rpmsgnsregisterdevice+0x24/0x30 [<000000008bbf8fa2>] rpmsgprobe+0x2e0/0x3ec [<00000000e65a68df>] virtiodevprobe+0x1c0/0x280 [<00000000443331cc>] reallyprobe+0xbc/0x2dc [<00000000391064b1>] driverprobedevice+0x78/0xe0 [<00000000a41c9a5b>] driverprobedevice+0xd8/0x160 [<000000009c3bd5df>] deviceattachdriver+0xb8/0x140 [<0000000043cd7614>] busforeachdrv+0x7c/0xd4 [<000000003b929a36>] deviceattach+0x9c/0x19c [<00000000a94e0ba8>] deviceinitialprobe+0x14/0x20 [<000000003c999637>] busprobedevice+0xa0/0xac

A vulnerability in the lsi53c895a device affects the latest version of qemu. A DMA-MMIO reentrancy problem may lead to memory corruption bugs like stack overflow or use-after-free.

blk-mq: fix IO hang from sbitmap wakeup race

In the Linux kernel, the following vulnerability has been resolved:

tracing: Ensure visibility when inserting an element into tracingmap

Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries:

$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/trigger cat /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)

The warning looks as follows:

[ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracingmap.c:983 tracingmapsortentries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsiibft(E) iscsibootsysfs(E) rfkill(E) afpacket(E) nlsiso88591(E) nlscp437(E) vfat(E) fat(E) ena(E) tinypowerbutton(E) qemufwcfg(E) button(E) fuse(E) efipstore(E) iptables(E) xtables(E) xfs(E) libcrc32c(E) aesceblk(E) aescecipher(E) crct10difce(E) polyvalce(E) polyvalgeneric(E) ghashce(E) gf128mul(E) sm4cegcm(E) sm4ceccm(E) sm4ce(E) sm4cecipher(E) sm4(E) sm3ce(E) sm3(E) sha3ce(E) sha512ce(E) sha512arm64(E) sha2ce(E) sha256arm64(E) nvme(E) sha1ce(E) nvmecore(E) nvmeauth(E) t10pi(E) sg(E) scsimod(E) scsicommon(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppccpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracingmapsortentries+0x3e0/0x408 [ 2911.184667] lr : tracingmapsortentries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracingmapsortentries+0x3e0/0x408 [ 2911.195220] histshow+0x124/0x800 [ 2911.195692] seqreaditer+0x1d4/0x4e8 [ 2911.196193] seqread+0xe8/0x138 [ 2911.196638] vfsread+0xc8/0x300 [ 2911.197078] ksysread+0x70/0x108 [ 2911.197534] arm64sysread+0x24/0x38 [ 2911.198046] invokesyscall+0x78/0x108 [ 2911.198553] el0svccommon.constprop.0+0xd0/0xf8 [ 2911.199157] doel0svc+0x28/0x40 [ 2911.199613] el0svc+0x40/0x178 [ 2911.200048] el0t64synchandler+0x13c/0x158 [ 2911.200621] el0t64sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]---

The problem appears to be caused by CPU reordering of writes issued from tracingmapinsert().

The check for the presence of an element with a given key in this function is:

val = READONCE(entry->val); if (val && keysmatch(key, val->key, map->keysize)) ...

The write of a new entry is:

elt = getfreeelt(map); memcpy(elt->key, key, map->keysize); entry->val = elt;

The "memcpy(elt->key, key, map->keysize);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---

In the Linux kernel, the following vulnerability has been resolved:

vfio/fsl-mc: Block calling interrupt handler without trigger

The eventfdctx trigger pointer of the vfiofslmcirq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between requestirq() and freeirq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive.

The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.

In the Linux kernel, the following vulnerability has been resolved:

vfio/pci: Disable auto-enable of exclusive INTx IRQ

Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in requestirq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio.

Instead, invert the logic using IRQFNOAUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.

Fixed bug GHSA-h746-cjrr-wfmr (passwordverify can erroneously return true, opening ATO risk). (CVE-2024-3096)

In the Linux kernel, the following vulnerability has been resolved:

xen/events: close evtchn after mapping cleanup

shutdownpirq and startuppirq are not taking the irqmappingupdatelock because they can't due to lock inversion. Both are called with the irqdesc->lock being taking. The lock order, however, is first irqmappingupdatelock and then irqdesc->lock.

This opens multiple races: - shutdownpirq can be interrupted by a function that allocates an event channel:

CPU0 CPU1 shutdownpirq { xenevtchnclose(e) startuppirq { EVTCHNOPbindpirq -> returns just freed evtchn e setevtchntoirq(e, irq) } xenirqinfocleanup() { setevtchntoirq(e, -1) } }

Assume here event channel e refers here to the same event channel number. After this race the evtchntoirq mapping for e is invalid (-1).

- startuppirq races with unbindfromirq in a similar way. Because startuppirq doesn't take irqmappingupdatelock it can grab the evtchn that unbindfromirq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchntoirq.

The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchntoirq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup.

On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvmesetupioqueues, pcifreeirq is called for every device which results in a call to shutdownpirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdownpirq and startuppirq are running potentially in parallel.

------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/eventsbase.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x8664 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvmeresetwork RIP: 0010:bindevtchntocpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? showtraceloglvl+0x1c1/0x2d9 ? showtraceloglvl+0x1c1/0x2d9 ? setaffinityirq+0xdc/0x1c0 ? diebody.cold+0x8/0xd ? die+0x2b/0x50 ? dotrap+0x90/0x110 ? bindevtchntocpu+0xdf/0xf0 ? doerrortrap+0x65/0x80 ? bindevtchntocpu+0xdf/0xf0 ? excinvalidop+0x4e/0x70 ? bindevtchntocpu+0xdf/0xf0 ? asmexcinvalidop+0x12/0x20 ? bindevtchntocpu+0xdf/0x ---truncated---

Accounts. The issue was addressed with improved checks.

Last updated 24 July 2024

After a failed cache insertion, addgetnetgrentX tries to send the non-existing response after the not-found header.

In addinnetgrX, addgetnetgrentX may have produced a NULL result, indicating a not-found status, but this is not handled in the subsequent code that prepares the record that will be sent out to the client.

Reference: https://sourceware.org/bugzilla/showbug.cgi?id=31678

An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

A flaw in the Linux Kernel found in the Open vSwitch Kernel module.

The Netlink copy code in the ovs kernel module attempts to make an in-kernel copy of the actions required. That means that when recursive operations, like sample(), clone(), decttl(), etc include additional actions, the code pushes a new stack frame and recursively calls into the code block.

Unfortunately, OVS module doesn't validate the stack depth, and will push too many frames causing a stack overflow which can lead to crash.

Reference: https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/

Vulnerability

PreparedStatement.setText(int, InputStream) and

PreparedStatemet.setBytea(int, InputStream)

will create a temporary file if the InputStream is larger than 51k

Example of vulnerable code:

java String s = "some very large string greater than 51200 bytes";

PreparedStatement.setInputStream(1, new ByteArrayInputStream(s.getBytes()) ); This will create a temporary file which is readable by other users on Unix like systems, but not MacOS.

Impact On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system.

This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability.

When analyzing the impact of this vulnerability, here are the important questions to ask:

Is the driver running in an environment where the OS has other untrusted users. If yes, and you answered 'yes' to question 1, this vulnerability impacts you. If no, this vulnerability does not impact you. Patches Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using.

Java 1.8 and higher users: this vulnerability is fixed in 42.2.27, 42.3.8, 42.4.3, 42.5.1 Java 1.7 users: this vulnerability is fixed in 42.2.27.jre7 Java 1.6 and lower users: no patch is available; you must use the workaround below. Workarounds If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability.

References CWE-200: Exposure of Sensitive Information to an Unauthorized Actor Fix commit https://github.com/pgjdbc/pgjdbc/commit/9008dc9aade6dbfe4efafcd6872ebc55f4699cf5 Similar Vulnerabilities Google Guava - https://github.com/google/guava/issues/4011 Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824

A vulnerability was found in Redis. This flaw allows authenticated users to use the HINCRBYFLOAT command to create an invalid hash field that may crash Redis on access.

Eclipse Jetty is vulnerable to a denial of service, caused by an error when handling a request containing multiple Accept headers with a large number of quality parameters. By sending a specially-crafted request, a remote attacker could exploit this vulnerability to exhaust minutes of CPU time.

Impact If GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection and if an attacker can send a request with a body that is received entirely by not consumed by the application, then a subsequent request on the same connection will see that body prepended to it's body.

The attacker will not see any data, but may inject data into the body of the subsequent request

CVE score is 4.8 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Workarounds The problem can be worked around by either: - Disabling compressed request body inflation by GzipHandler. - By always fully consuming the request content before sending a response. - By adding a Connection: close to any response where the servlet does not fully consume request content.

It was discovered in Undertow that the code that parsed the HTTP request line permitted invalid characters. This could be exploited, in conjunction with a proxy that also permitted the invalid characters but with a different interpretation, to inject data into the HTTP response. By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack, or obtain sensitive information from requests other than their own.

Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.

Older, EOL versions may also be affected.

Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.