| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
batman-adv: reject unrepresentable multicast TVLV offsets
The network and transport header fields in struct sk_buff are 16-bit
offsets from skb->head, and U16_MAX is reserved as the unset transport
header value. batadv_tvlv_call_handler() sets both fields from a received
multicast TVLV without checking whether the TVLV end is representable.
If the end offset exceeds the field's range, skb_set_transport_header()
truncates it so that the transport header precedes the network header.
The negative difference is then returned by skb_network_header_len() as
a large u32. batadv_mcast_forw_packet() consequently accepts an oversized
multicast tracker and accesses memory beyond the skb data.
Add skb_set_transport_header_careful(), an offset-aware counterpart to
skb_reset_transport_header_careful(), which validates the final
head-relative offset before assigning it. Use the new helper in
batadv_tvlv_call_handler() and reject unrepresentable TVLVs before
setting the network header. |
| DeadLetterPublishingRecovererFactory reads the retry_topic-original-timestamp header from an inbound ConsumerRecord and passes its raw bytes directly to new BigInteger(header.value()) with no length or format validation.
Spring for Apache Kafka 4.1.0
Spring for Apache Kafka 4.0.0 - 4.0.6
Spring for Apache Kafka 3.0.0 - 3.3.16
Spring for Apache Kafka 2.9.0 - 2.9.14
Spring for Apache Kafka 2.8.12 and earlier |
| FreeIPMI before 1.6.19 has a stack-based buffer overflow in _read_fru_data in libfreeipmi/fru/ipmi-fru.c when a BMC returns more bytes than requested. |
| A heap-based buffer overflow was found in Corosync's Totem Process Group (totempg) message reassembly. When processing fragmented multicast messages, the buffer used to reassemble fragments lacks a runtime bounds check in release builds. A network-adjacent attacker able to send crafted multicast protocol messages to the cluster could cause a heap buffer overflow with attacker-controlled data. This can crash the Corosync daemon, causing a denial of service to the entire cluster, and may potentially allow further exploitation given sufficient heap-corruption control. |
| There is an out-of-bounds read vulnerability in DASYLab due to improper validation of user-supplied data. This results in a read a past the end of an allocated heap buffer during string conversion. Successful exploitation requires an attacker to get a user to open a specially crafted .DSB file. This issue affects all versions before 2026.0.0. |
| There is an out-of-bounds read vulnerability in DASYLab due to improper validation of user-supplied data. This results in a read outside the bounds of an allocated data structure. Successful exploitation requires an attacker to get a user to open a specially crafted .DSB file. This issue affects all versions before 2026.0.0. |
| There is an out-of-bounds read vulnerability in DASYLab due to improper validation of user-supplied data. This results in a read a few bytes past the end of an allocated heap buffer during file handling. Successful exploitation requires an attacker to get a user to open a specially crafted .DSB file. This issue affects all versions before 2026.0.0. |
| A
stack-based buffer overflow vulnerability exists in the EasyMesh module of
TP-Link Archer AX55 v4. When Mesh mode is enabled, a LAN attacker may submit
crafted input that causes the easymesh daemon to crash and may potentially
achieve remote code execution on the device.
Successful
exploitation may cause the EasyMesh daemon to crash and may potentially allow
remote code execution when Mesh mode is enabled. This
may result in high impact to the confidentiality, integrity, and availability
of the affected device. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7925: ensure tx headroom in usb_sdio_tx_prepare_skb
mt7925_usb_sdio_tx_prepare_skb() pushes a TX descriptor and a USB
header onto every skb and assumes the headroom for them is already
there. That holds for locally generated traffic, where mac80211
reserves hw->extra_tx_headroom, but forwarded frames are sent through
ieee80211_8023_xmit(), which does not reserve it. Bridge a wired
interface to an mt7925u AP and the first forwarded frame that arrives
short panics the kernel:
skbuff: skb_under_panic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1
kernel BUG at net/core/skbuff.c:212!
Call trace:
skb_panic+0x58/0x60 (P)
skb_push+0x58/0x60
mt7925_usb_sdio_tx_prepare_skb+0xf8/0x1b8 [mt7925_common]
mt76u_tx_queue_skb+0xa0/0x1f8 [mt76_usb]
__mt76_tx_queue_skb+0x54/0xe8 [mt76]
mt76_txq_schedule.part.0+0x204/0x478 [mt76]
mt76_txq_schedule_all+0x50/0x80 [mt76]
mt792x_tx_worker+0x68/0x100 [mt792x_lib]
__mt76_worker_fn+0x84/0x150 [mt76]
Whether a given setup hits it depends on how much headroom the ingress
netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging
onboard ethernet to a Netgear A9000; originally reported on an MT7986
router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet),
which leaves more headroom, helped narrow the trigger to the ingress
path.
The same bug was fixed on mt7921 by commit 98c4d0abf5c4 ("mt76:
mt7921: don't assume adequate headroom for SDIO headers"), but mt7925
was copied from mt7921 without the fix. Add the same guard here. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: serial: option: fix slab OOB read in interrupt URB callback
The interrupt URB buffer is allocated in setup_port_interrupt_in() based
on the endpoint's wMaxPacketSize:
buffer_size = usb_endpoint_maxp(epd);
port->interrupt_in_buffer = kmalloc(buffer_size, GFP_KERNEL);
When a USB device declares wMaxPacketSize = 8 on its interrupt IN
endpoint, the buffer is allocated from kmalloc-8 cache (exactly
8 bytes).
If the device sends a short packet (actual_length < wMaxPacketSize),
the URB completes with status == 0 and the callback proceeds to read:
data[sizeof(struct usb_ctrlrequest)]
which evaluates to data[8], accessing 1 byte beyond the allocated 8-byte
buffer. This results in a slab out-of-bounds read.
Fix this by adding the missing bounds check: first verify that the
actual length is large enough to contain the struct usb_ctrlrequest
header before accessing req_pkt->bRequestType and req_pkt->bRequest,
and then verify that there is an additional byte for the modem signal
state before reading data[sizeof(struct usb_ctrlrequest)] inside the
conditional. Use sizeof(*req_pkt) instead of sizeof(struct
usb_ctrlrequest) for consistency.
[ johan: use dev_err(); split signals declaration and initialisation ] |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: sun8i-ss - Remove crypto_rng interface
Since the crypto_rng interface for hardware PRNGs is unused and is
redundant with hwrng and the actual Linux RNG, it's being phased out.
Most drivers for it were already removed. Go ahead and remove the
sun8i-ss support which is one of the only remaining ones.
As usual for crypto_rng, this driver was also buggy: its ->generate()
function had a use-after-free vulnerability due to using
wait_for_completion_interruptible_timeout() without handling shutting
down the DMA operation if a signal is sent. Also, it had a buffer
overread bug in the line 'memcpy(ctx->seed, d + dlen, ctx->slen);'.
There's no point in fixing these bugs separately only to remove the code
anyway, so this commit is marked with Fixes and Cc stable. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec()
io_vec_fill_bvec() computes the folio size with a plain int 1:
unsigned long folio_size = 1 << imu->folio_shift;
imu->folio_shift is unsigned int and comes from folio_shift() of the
folio backing the registered buffer, so it can be 32 or more on a 64 bit
kernel. Shifting int 1 that far is undefined, and on x86 and arm64 the
count is taken modulo 32, so a shift of 34 yields 4 rather than 16G.
Every other folio_shift shift in this file already uses 1UL.
The result is that the segment estimate and the fill loop disagree.
io_estimate_bvec_size() sizes the bvec array with the real shift:
max_segs += (iov[i].iov_len >> shift) + 2;
so a 1M iovec on a 16G folio is charged 2 segments, while
io_vec_fill_bvec() then walks the same iovec in folio_size chunks of 4
bytes and writes res_bvec[bvec_idx] a quarter of a million times, past
the end of the array it was given. src_bvec is advanced once per
iteration as well, so imu->bvec is read past its end at the same time.
validate_fixed_range() only checks that the range is inside the
registered buffer and does not bound the segment count.
Reaching it needs a folio with a shift of at least 32, which means a
gigantic hugetlb page: 16G on arm64 with 64K pages, where
CONT_PMD_SHIFT is 34 and hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT)
registers that size, and likewise on powerpc. x86_64 tops out at 1G, so
a shift of 30, which still fits in int and is unaffected.
Use 1UL, as the rest of the file does. |
| NIOSSLCertificate._subjectAlternativeNames provides access to the raw bytes for a cert's SANs. NIOSSL provides access to a buffer assumed to be backed by an ASN1_STRING, but not all SANs are backed by ASN1_STRING, so accessing the buffer for such a type can lead to out-of-bounds memory access. This vulnerability is addressed in swift-nio-ssl version 2.37.2. |
| MOOS core-moos through 10.4.0 contains a buffer over-read vulnerability in CMOOSCommPkt where a four-byte packet triggers out-of-bounds memory access during deserialization. Attackers can open a TCP connection to the MOOSDB port and send a crafted short packet to read memory before authentication. |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote authenticated attacker to cause a denial of service due to a stack-based buffer overflow. |
| A maliciously crafted PDF file, when parsed through Autodesk Revit, can force an Out-of-Bounds Read vulnerability. A malicious actor can leverage this vulnerability to cause a crash, read sensitive data, or execute arbitrary code in the context of the current process. |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: digital: clamp SENSF_RES length to the destination buffer
digital_in_recv_sensf_res() memcpy()s resp->len bytes from a remote
NFC-F device response into the NFC_SENSF_RES_MAXSIZE-byte target.sensf_res
field without an upper-bound check. A nearby malicious NFC-F device can
send an oversized SENSF_RES response to overflow the stack-local struct
nfc_target.
Clamp resp->len to NFC_SENSF_RES_MAXSIZE before the copy.
Found by 0sec automated security-research tooling (https://0sec.ai). |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: validate attr entry pointer before field access
xfs_attr3_leaf_verify_entry() accesses lentry/rentry fields (namelen,
valuelen) before checking if the entry pointer itself is within bounds.
If nameidx is crafted to point near the end of the buffer, these field
accesses can read out-of-bounds before the bounds check at
name_end > buf_end is performed.
Add explicit bounds checks for entry pointers before accessing their
fields. Use offsetof() to check that the start of the flexible array
member (nameval/name) is within bounds, which ensures all preceding
fields are safe to access. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_aml: validate firmware segment lengths
aml_download_firmware() reads two lengths from the firmware header and
uses them to build pointers before checking that the header and segment
data are present. A truncated or inconsistent firmware image can make
the driver read past firmware->data while constructing TCI commands.
Reject images shorter than the header and ensure that the ICCM and DCCM
ranges fit within the loaded firmware before downloading either segment. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: dummy: Check card index validity at probe
snd_dummy_probe() blindly trusts that the given devptr->id value is
within the proper card index range. It's OK for the devices the
driver itself creates at the module probe time, but if the device is
bound manually via sysfs interface, this could be -1 as "none", and
this leads to OOB access for index[] and other parameters.
Add a sanity check for the card index and warn/correct it if it's a
value out of the range. |
