Buffer overflow in OpenVPN ovpn-dco-win version 1.3.0 and earlier and version 2.5.8 and earlier allows a local user process to send a too large control message buffer to the kernel driver resulting in a system crash

A flaw was found in indent, a program for formatting C code. This issue may allow an attacker to trick a user into processing a specially crafted file to trigger a heap-based buffer overflow, causing the application to crash.

Cloudflare version of zlib library was found to be vulnerable to memory corruption issues affecting the deflation algorithm implementation (deflate.c). The issues resulted from improper input validation and heap-based buffer overflow. A local attacker could exploit the problem during compression using a crafted malicious file potentially leading to denial of service of the software. Patches: The issue has been patched in commit 8352d10 https://github.com/cloudflare/zlib/commit/8352d108c05db1bdc5ac3bdf834dad641694c13c . The upstream repository is not affected.

Tensorflow is an Open Source Machine Learning Framework. The TFG dialect of TensorFlow (MLIR) makes several assumptions about the incoming `GraphDef` before converting it to the MLIR-based dialect. If an attacker changes the `SavedModel` format on disk to invalidate these assumptions and the `GraphDef` is then converted to MLIR-based IR then they can cause a crash in the Python interpreter. Under certain scenarios, heap OOB read/writes are possible. These issues have been discovered via fuzzing and it is possible that more weaknesses exist. We will patch them as they are discovered.

In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix out-of-bounds TLB allocations with CONFIG_SWIOTLB_DYNAMIC Limit the free list length to the size of the IO TLB. Transient pool can be smaller than IO_TLB_SEGSIZE, but the free list is initialized with the assumption that the total number of slots is a multiple of IO_TLB_SEGSIZE. As a result, swiotlb_area_find_slots() may allocate slots past the end of a transient IO TLB buffer.

In ril service, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service with System execution privileges needed

In ril service, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service with System execution privileges needed

jq is a command-line JSON processor. Version 1.7 is vulnerable to stack-based buffer overflow in builds using decNumber. Version 1.7.1 contains a patch for this issue.

jq is a command-line JSON processor. Version 1.7 is vulnerable to heap-based buffer overflow. Version 1.7.1 contains a patch for this issue.

In video decoder, there is a possible out of bounds write due to improper input validation. This could lead to local denial of service with no additional execution privileges needed

In video decoder, there is a possible out of bounds write due to improper input validation. This could lead to local denial of service with no additional execution privileges needed

In video decoder, there is a possible out of bounds write due to improper input validation. This could lead to local denial of service with no additional execution privileges needed

In video decoder, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service with no additional execution privileges needed

GPAC 2.3-DEV-rev605-gfc9e29089-master contains a heap-buffer-overflow in ffdmx_parse_side_data /afltest/gpac/src/filters/ff_dmx.c:202:14 in gpac/MP4Box.

GPAC 2.3-DEV-rev605-gfc9e29089-master contains a SEGV in gpac/MP4Box in gf_media_change_pl /afltest/gpac/src/media_tools/isom_tools.c:3293:42.

A Stack-based Buffer Overflow vulnerability in the CLI command of Juniper Networks Junos and Junos EVO allows a low privileged attacker to execute a specific CLI commands leading to Denial of Service. Repeated actions by the attacker will create a sustained Denial of Service (DoS) condition. This issue affects Juniper Networks: Junos OS: * All versions prior to 19.1R3-S10; * 19.2 versions prior to 19.2R3-S7; * 19.3 versions prior to 19.3R3-S8; * 19.4 versions prior to 19.4R3-S12; * 20.2 versions prior to 20.2R3-S8; * 20.4 versions prior to 20.4R3-S8; * 21.2 versions prior to 21.2R3-S6; * 21.3 versions prior to 21.3R3-S5; * 21.4 versions prior to 21.4R3-S4; * 22.1 versions prior to 22.1R3-S3; * 22.2 versions prior to 22.2R3-S1; * 22.3 versions prior to 22.3R3; * 22.4 versions prior to 22.4R2. Junos OS Evolved: * All versions prior to 20.4R3-S8-EVO; * 21.2 versions prior to 21.2R3-S6-EVO; * 21.3 versions prior to 21.3R3-S5-EVO; * 21.4 versions prior to 21.4R3-S4-EVO; * 22.1 versions prior to 22.1R3-S3-EVO; * 22.2 versions prior to 22.2R3-S1-EVO; * 22.3 versions prior to 22.3R3-EVO; * 22.4 versions prior to 22.4R2-EVO.

In faceid service, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service with no additional execution privileges

IBM Spectrum Protect Client 7.1 and 8.1 is vulnerable to a stack based buffer overflow, caused by improper bounds checking. A local attacker could exploit this vulnerability and cause a denial of service. IBM X-Force ID: 214438.

GPAC 2.3-DEV-rev605-gfc9e29089-master contains a heap-buffer-overflow in gf_isom_use_compact_size gpac/src/isomedia/isom_write.c:3403:3 in gpac/MP4Box.

In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c