| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, PostOffice.subscribe parses a shared-subscription filter through SharedSubscriptionUtils.extractShareName before validating the complete $share/{shareName}/{topicFilter} structure. A remote client can send a filter such as $share/grp without a topic-filter portion, causing a StringIndexOutOfBoundsException while calculating the share name. The exception terminates command handling on the shared session event loop and can deny service to other client sessions assigned to that loop. This issue is fixed in version 0.18.1. |
| Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, the broker does not enforce a maximum length for pending per-session message queues. When a fast publisher sends messages to a slow subscriber whose in-flight window is full, queued messages can accumulate without bound in memory or persistent storage. Remote clients can use this condition to exhaust broker resources and cause a denial of service. This issue is fixed in version 0.18.1. |
| Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, PostOffice.publishWill publishes a client's Last-Will message without applying the canWrite authorization and reserved-topic checks used for a normal PUBLISH. A client can configure a Will for a topic that the client is not permitted to write and cause the broker to publish the unauthorized message when the client disconnects unexpectedly. This issue allows unauthorized message injection into restricted topics. This issue is fixed in version 0.18.1. |
| In the Linux kernel, the following vulnerability has been resolved:
cachefiles: Fix potential UAF/KASAN warning
Currently, trace_cachefiles_coherency() is being passed a pointer to a
__be64 lain over the coherency data in struct cachefiles_xattr so that it
can display the first 8 bytes. However, the data is of variable length and
could even be 0 bytes. This could lead to a UAF or KASAN warning.
Fix this by making sure the buffer has room for at least 8 bytes and that
those 8 bytes are pre-cleared.
Further, those bytes are not 8-byte aligned, so fix the tracepoint to
extract the data as four 2-byte words (they are 2-byte aligned) and
reassemble the __be64. The compiler will convert this into a single 8-byte
load where the CPU supports it. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add()
mpi3mr_get_tgtdev_by_addr() increments the target device kref when it
returns a device. If a subsequent error triggers a goto out_fail after
the tgtdev reference is acquired, the reference is never released
because the out_fail path does not call mpi3mr_tgtdev_put(). This
prevents the target device structure from ever being freed.
Add a tgtdev put in the out_fail path, guarded by a NULL check since
tgtdev is only acquired for SAS_END_DEVICE types and the same cleanup
path is shared by earlier error cases where tgtdev is still NULL. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add()
sas_port_alloc_num() can return NULL on memory allocation failure. The
return value is passed directly to sas_port_add() without a NULL check,
which causes a NULL pointer dereference.
Additionally, if sas_port_add() fails, the allocated port is not freed
before jumping to out_fail, leaking the sas_port structure. Call
sas_port_free() to properly release it. |
| In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix dma mapping leak in stmmac_tso_xmit()
In stmmac_tso_xmit(), if the DMA mapping of an skb fragment fails, the
frame is dropped but the DMA mappings already created for the linear
part and for the fragments mapped before the failure are never
unmapped, leaking DMA mappings.
Fix the leak by walking back over the descriptors used by the frame and
releasing each of them with stmmac_free_tx_buffer(). Moreover, release
the descriptors with stmmac_release_tx_desc() unmapping the DMA buffers. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: check_cond_jmp_op(): properly infer if register is null
Nicholas Carlini reported a bug when verifier can incorrectly infer
that a pointer is non-null. The bug occurs when two pointers are
compared and one of them has a type w/o PTR_MAYBE_NULL flag,
but which allows a value to be NULL at runtime.
Here is an example:
// `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED
// `a` is 0 at runtime.
// `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL
void *a = bpf_rdonly_cast(0, 0);
int *b = bpf_map_lookup_elem(...);
if (a == b)
*b = 42; // verifier does not catch null pointer dereference
This happens because of a special case in check_cond_jmp_op(),
which attempts to strip PTR_MAYBE_NULL flags from pointer types,
when processing comparisons like `rA == rB`, if either rA or rB can't
be null.
The non-null property is derived based on the absence of
PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient
for types like PTR_TO_MEM, as in the example.
This patch replaces type_may_be_null() call with reg_not_null(),
which contains an allowlist of types for which absence of
PTR_MAYBE_NULL actually means that the value can't be NULL at runtime.
At the moment, the list in the reg_not_null() omits two types for
which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF.
In order to remain backward compatible, and assuming that only
comparison between pointers of the same type makes sense,
this commit extends reg_not_null(). W/o such an extension e.g.
verifier_jeq_infer_not_null/null_ptr_to_map_value fails.
reg_not_null() can be extended further, but I deem that out of scope
for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID
checks in the check_cond_jmp_op() can be removed with migration to
reg_not_null(), but that is a behavioural change, as the special case
would start matching for PTR_TO_BTF_ID that is also is_trusted_reg().
I omit the behavioural change from this commit. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: reject invalid sectors_per_cluster in the boot sector
is_boot_sector_ntfs() checks the boot sector's sectors_per_cluster field
with a range test that rejects 0x81..0xf3 but accepts 0 and other
non-power-of-two counts. A zero value reaches parse_ntfs_boot_sector():
sectors_per_cluster_bits = ffs(sectors_per_cluster) - 1;
...
vol->cluster_size = vol->sector_size << sectors_per_cluster_bits;
ffs(0) is 0, so sectors_per_cluster_bits becomes (unsigned)-1 and the
shift is undefined:
UBSAN: shift-out-of-bounds in fs/ntfs/super.c:673:39
shift exponent 4294967295 is too large for 32-bit type 'int'
This change rejects any non-power-of-two value, since it feeds the
aforementioned shift via ffs() - 1, which only yields the correct shift for a
power of two. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: bound $AttrDef table walk to the loaded table size
ntfs_attr_find_in_attrdef() walks the in-memory $AttrDef table, but the
loop condition bounds only the start of each entry, not the whole entry:
for (ad = vol->attrdef; (u8 *)ad - (u8 *)vol->attrdef <
vol->attrdef_size && ad->type; ++ad)
struct attr_def is 160 bytes; the guard reads ad->type at offset 128 and
the loop body reads further fields. vol->attrdef is kvzalloc(i_size),
where i_size is the on-disk $AttrDef data size, checked in
load_and_init_attrdef() only as 0 < i_size <= 0x7fffffff. A volume whose
$AttrDef data size is smaller than one entry (e.g. 120 bytes) makes the
read of ad->type run past the allocation. Creating a file reaches this
through ntfs_attr_size_bounds_check() and reads out of bounds:
BUG: KASAN: slab-out-of-bounds in ntfs_attr_find_in_attrdef+0x66/0xa0
Read of size 4 at addr ffff888005833280 by task init/1
ntfs_attr_find_in_attrdef
ntfs_attr_size_bounds_check
ntfs_attr_can_be_non_resident
ntfs_attr_add
Require the whole entry to lie within attrdef_size in the loop guard, and
reject at mount a $AttrDef too small to hold one attr_def entry. |
| Out-of-bounds Write in the natural width branch of the text sizing protocol in kitty from 0.40.0 before 0.49.0 allows a program writing to the terminal to write past the end of a fixed-size buffer, because screen_handle_multicell_command() in kitty/screen.c appends each codepoint of a grapheme cluster with lc.chars[lc.count++] = ch without any capacity check, while lc is declared by the RAII_ListOfChars macro as a four-element char_type array in the function's stack frame, so an OSC 66 escape code whose payload carries a grapheme cluster longer than four codepoints writes beyond that buffer, one 32-bit value per additional codepoint, in the order the codepoints appear. Where the cluster is preceded in the same payload by a sequence that causes an intermediate flush, the buffer is first migrated to the heap by ensure_space_for_chars() and the write occurs past the heap allocation instead. This results in termination of the kitty process and therefore of all its windows, tabs and child processes. |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in dashbitco lazy_html allows mutation XSS via a parse and serialize round-trip of attacker-supplied HTML.
LazyHTML.to_html/2 and LazyHTML.Tree.to_html/2 decide whether to escape an element's text from its tag name alone. A style or script element inside SVG or MathML foreign content is parsed with character references decoded, but is serialized as an HTML raw-text element, so its text is emitted unescaped. Encoded markup such as </style><img src=x onerror=...> inside <svg><style> therefore closes the element on re-parse and becomes live markup. Applications that parse untrusted HTML with lazy_html, filter the document or tree, and serialize it for display are affected, since the payload is a plain text node that no element or attribute filter sees.
This issue affects lazy_html: from 0.1.0 before 0.1.13. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Enhance OEM ID and Table ID validation in acpi_ex_load_table_op()
Enhance OEM ID and Table ID validation in acpi_ex_load_table_op() to
prevent buffer overflows. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Fix NULL pointer dereference in acpi_ns_custom_package()
acpi_ns_custom_package() unconditionally dereferences the first element
of the package to read the _BIX version number, without checking for
NULL:
if ((*Elements)->Common.Type != ACPI_TYPE_INTEGER)
When firmware returns a _BIX package whose first element is an
unresolvable reference, ACPICA evaluates that entry to NULL.
acpi_ns_remove_null_elements() does not strip NULL entries for
ACPI_PTYPE_CUSTOM packages (fixed-position format would break if
elements were shifted), so acpi_ns_custom_package() sees the NULL
and causes a crash.
Add a NULL check for the first element (version field) before
dereferencing it. The caller then receives AE_AML_OPERAND_TYPE
instead of crashing. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPICA: add boundary checks in two places
Add boundary checks in acpi_ps_get_next_namestring() and
acpi_ps_peek_opcode() to prevent out-of-bounds access. |
| In the Linux kernel, the following vulnerability has been resolved:
perf/ftrace: Fix WARNING in __unregister_ftrace_function
perf_ftrace_function_unregister() unconditionally calls
unregister_ftrace_function() without checking whether the ftrace_ops
was ever successfully registered. This triggers a WARN_ON in
__unregister_ftrace_function() when the ops doesn't have
FTRACE_OPS_FL_ENABLED set.
This can happen during perf_event_alloc() error cleanup when
perf_trace_destroy() is called via __free_event() on an event whose
ftrace_ops registration failed or was already torn down by
perf_try_init_event()'s err_destroy path.
The call path is:
perf_event_alloc() error cleanup
-> __free_event()
-> event->destroy() [tp_perf_event_destroy]
-> perf_trace_destroy()
-> perf_trace_event_close()
-> TRACE_REG_PERF_CLOSE
-> perf_ftrace_function_unregister()
-> unregister_ftrace_function()
-> __unregister_ftrace_function()
-> WARN_ON(!(ops->flags & FTRACE_OPS_FL_ENABLED))
Fix this by checking FTRACE_OPS_FL_ENABLED before attempting to
unregister. If the ops is not enabled, just free the filter and
return success. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix invalid data access in ath11k_dp_rx_h_undecap_nwifi
In certain cases, hardware might provide packets with a
length greater than the maximum native Wi-Fi header length.
This can lead to accessing and modifying fields in the header
within the ath11k_dp_rx_h_undecap_nwifi() function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and
potentially result in invalid data access and memory corruption.
Kernel stack is corrupted in: ath11k_dp_rx_h_undecap+0x6b0/0x6b0 [ath11k]
Call trace:
ath11k_dp_rx_h_mpdu+0x0/0x2e8 [ath11k]
ath11k_dp_rx_h_mpdu+0x1e0/0x2e8 [ath11k]
ath11k_dp_rx_wbm_err+0x1e0/0x450 [ath11k]
ath11k_dp_rx_process_wbm_err+0x2fc/0x460 [ath11k]
ath11k_dp_service_srng+0x2e0/0x348 [ath11k]
Add a sanity check before processing the SKB to prevent invalid
data access in the undecap native Wi-Fi function for the
DP_RX_DECAP_TYPE_NATIVE_WIFI decap type.
This adapted from the discussion/patch of the ath12k driver [1].
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 |
| In the Linux kernel, the following vulnerability has been resolved:
ata: ahci: fail probe if BAR too small for claimed ports
When an AHCI controller is disabled in BIOS, its HOST_CAP register may
contain a bogus value, e.g. 0xFFFFFFFF.
Since CAP.NP (Number of Ports) is a zeroes based 5-bit register field,
a value of 0x1f means 32 ports. If CAP.NP claims more ports than can
physically fit within the mapped BAR region, accessing port registers
beyond the BAR boundary causes a kernel panic.
Add validation in ahci_init_one() to check that the BAR size is
sufficient for the number of ports claimed in CAP.NP. The check
calculates the required MMIO size as:
required_size = 0x100 (global registers) + max_ports * 0x80
If required_size exceeds the actual BAR size, the probe fails with
-ENODEV, preventing the panic and providing a clear error message.
[cassel: commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
net: qrtr: fix node refcount leak on ctrl packet alloc failure
qrtr_send_resume_tx() calls qrtr_node_lookup() which takes a
reference on the returned node. If the subsequent call to
qrtr_alloc_ctrl_packet() fails due to memory allocation failure, the
function returns -ENOMEM without calling qrtr_node_release() to
release the node reference.
Add qrtr_node_release(node) before returning on the allocation failure
path to properly release the reference. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: preserve non-DOS attribute bits in system.dos_attrib
[BUG]
A corrupted ntfs3 image can hit a NULL function pointer call in
generic_perform_write() after toggling system.ntfs_attrib and then
overwriting system.dos_attrib on the same file.
BUG: kernel NULL pointer dereference, address: 0000000000000000
\#PF: supervisor instruction fetch in kernel mode
\#PF: error_code(0x0010) - not-present page
PGD bed5067 P4D bed5067 PUD 0
Oops: Oops: 0010 [#1] SMP KASAN NOPTI
RIP: 0010:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 0018:ffff88801025f988 EFLAGS: 00010246
Call Trace:
generic_perform_write+0x409/0x8c0 mm/filemap.c:4255
__generic_file_write_iter+0x1bb/0x200 mm/filemap.c:4372
ntfs_file_write_iter+0xcd9/0x1c20 fs/ntfs3/file.c:1253
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x63b/0xf70 fs/read_write.c:686
ksys_write+0x133/0x250 fs/read_write.c:738
__do_sys_write fs/read_write.c:749 [inline]
__se_sys_write fs/read_write.c:746 [inline]
__x64_sys_write+0x77/0xc0 fs/read_write.c:746
...
[CAUSE]
system.ntfs_attrib updates ATTR_DATA flags via ni_new_attr_flags()
and switches i_mapping->a_ops to ntfs_aops_cmpr when
FILE_ATTRIBUTE_COMPRESSED is set. system.dos_attrib then overwrites
ni->std_fa from a one-byte DOS attribute value, clearing the compression
bit without updating ATTR_DATA or the mapping operations.
Old buffered writes use is_compressed(ni) to choose
__generic_file_write_iter(). That leaves generic_perform_write() calling
a NULL write_begin callback from ntfs_aops_cmpr.
[FIX]
Treat system.dos_attrib as a low-byte DOS attribute update and preserve the
existing non-DOS attribute bits in ni->std_fa. This keeps compressed and
sparse state consistent with ATTR_DATA and the mapping operations while
keeping the existing DOS attribute semantics intact. |
