| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: ismt: Fix an out-of-bounds bug in ismt_access()
When the driver does not check the data from the user, the variable
'data->block[0]' may be very large to cause an out-of-bounds bug.
The following log can reveal it:
[ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20
[ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE
[ 33.996475] ==================================================================
[ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b
[ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485
[ 33.999450] Call Trace:
[ 34.001849] memcpy+0x20/0x60
[ 34.002077] ismt_access.cold+0x374/0x214b
[ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0
[ 34.004007] i2c_smbus_xfer+0x10a/0x390
[ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710
[ 34.005196] i2cdev_ioctl+0x5ec/0x74c
Fix this bug by checking the size of 'data->block[0]' first. |
| In the Linux kernel, the following vulnerability has been resolved:
powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue
When value < time_unit, the parameter of ilog2() will be zero and
the return value is -1. u64(-1) is too large for shift exponent
and then will trigger shift-out-of-bounds:
shift exponent 18446744073709551615 is too large for 32-bit type 'int'
Call Trace:
rapl_compute_time_window_core
rapl_write_data_raw
set_time_window
store_constraint_time_window_us |
| In the Linux kernel, the following vulnerability has been resolved:
ixgbe: fix incorrect map used in eee linkmode
incorrectly used ixgbe_lp_map in loops intended to populate the
supported and advertised EEE linkmode bitmaps based on ixgbe_ls_map.
This results in incorrect bit setting and potential out-of-bounds
access, since ixgbe_lp_map and ixgbe_ls_map have different sizes
and purposes.
ixgbe_lp_map[i] -> ixgbe_ls_map[i]
Use ixgbe_ls_map for supported and advertised linkmodes, and keep
ixgbe_lp_map usage only for link partner (lp_advertised) mapping. |
| In the Linux kernel, the following vulnerability has been resolved:
cacheinfo: Fix shared_cpu_map to handle shared caches at different levels
The cacheinfo sets up the shared_cpu_map by checking whether the caches
with the same index are shared between CPUs. However, this will trigger
slab-out-of-bounds access if the CPUs do not have the same cache hierarchy.
Another problem is the mismatched shared_cpu_map when the shared cache does
not have the same index between CPUs.
CPU0 I D L3
index 0 1 2 x
^ ^ ^ ^
index 0 1 2 3
CPU1 I D L2 L3
This patch checks each cache is shared with all caches on other CPUs. |
| In the Linux kernel, the following vulnerability has been resolved:
phy: hisilicon: Fix an out of bounds check in hisi_inno_phy_probe()
The size of array 'priv->ports[]' is INNO_PHY_PORT_NUM.
In the for loop, 'i' is used as the index for array 'priv->ports[]'
with a check (i > INNO_PHY_PORT_NUM) which indicates that
INNO_PHY_PORT_NUM is allowed value for 'i' in the same loop.
This > comparison needs to be changed to >=, otherwise it potentially leads
to an out of bounds write on the next iteration through the loop |
| In the Linux kernel, the following vulnerability has been resolved:
jfs: jfs_dmap: Validate db_l2nbperpage while mounting
In jfs_dmap.c at line 381, BLKTODMAP is used to get a logical block
number inside dbFree(). db_l2nbperpage, which is the log2 number of
blocks per page, is passed as an argument to BLKTODMAP which uses it
for shifting.
Syzbot reported a shift out-of-bounds crash because db_l2nbperpage is
too big. This happens because the large value is set without any
validation in dbMount() at line 181.
Thus, make sure that db_l2nbperpage is correct while mounting.
Max number of blocks per page = Page size / Min block size
=> log2(Max num_block per page) = log2(Page size / Min block size)
= log2(Page size) - log2(Min block size)
=> Max db_l2nbperpage = L2PSIZE - L2MINBLOCKSIZE |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies()
Fix a slab-out-of-bounds read that occurs in kmemdup() called from
brcmf_get_assoc_ies().
The bug could occur when assoc_info->req_len, data from a URB provided
by a USB device, is bigger than the size of buffer which is defined as
WL_EXTRA_BUF_MAX.
Add the size check for req_len/resp_len of assoc_info.
Found by a modified version of syzkaller.
[ 46.592467][ T7] ==================================================================
[ 46.594687][ T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50
[ 46.596572][ T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7
[ 46.598575][ T7]
[ 46.599157][ T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #145
[ 46.601333][ T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 46.604360][ T7] Workqueue: events brcmf_fweh_event_worker
[ 46.605943][ T7] Call Trace:
[ 46.606584][ T7] dump_stack_lvl+0x8e/0xd1
[ 46.607446][ T7] print_address_description.constprop.0.cold+0x93/0x334
[ 46.608610][ T7] ? kmemdup+0x3e/0x50
[ 46.609341][ T7] kasan_report.cold+0x79/0xd5
[ 46.610151][ T7] ? kmemdup+0x3e/0x50
[ 46.610796][ T7] kasan_check_range+0x14e/0x1b0
[ 46.611691][ T7] memcpy+0x20/0x60
[ 46.612323][ T7] kmemdup+0x3e/0x50
[ 46.612987][ T7] brcmf_get_assoc_ies+0x967/0xf60
[ 46.613904][ T7] ? brcmf_notify_vif_event+0x3d0/0x3d0
[ 46.614831][ T7] ? lock_chain_count+0x20/0x20
[ 46.615683][ T7] ? mark_lock.part.0+0xfc/0x2770
[ 46.616552][ T7] ? lock_chain_count+0x20/0x20
[ 46.617409][ T7] ? mark_lock.part.0+0xfc/0x2770
[ 46.618244][ T7] ? lock_chain_count+0x20/0x20
[ 46.619024][ T7] brcmf_bss_connect_done.constprop.0+0x241/0x2e0
[ 46.620019][ T7] ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0
[ 46.620818][ T7] ? __lock_acquire+0x181f/0x5790
[ 46.621462][ T7] brcmf_notify_connect_status+0x448/0x1950
[ 46.622134][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 46.622736][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
[ 46.623390][ T7] ? find_held_lock+0x2d/0x110
[ 46.623962][ T7] ? brcmf_fweh_event_worker+0x19f/0xc60
[ 46.624603][ T7] ? mark_held_locks+0x9f/0xe0
[ 46.625145][ T7] ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
[ 46.625871][ T7] ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
[ 46.626545][ T7] brcmf_fweh_call_event_handler.isra.0+0x90/0x100
[ 46.627338][ T7] brcmf_fweh_event_worker+0x557/0xc60
[ 46.627962][ T7] ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
[ 46.628736][ T7] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 46.629396][ T7] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 46.629970][ T7] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 46.630649][ T7] process_one_work+0x92b/0x1460
[ 46.631205][ T7] ? pwq_dec_nr_in_flight+0x330/0x330
[ 46.631821][ T7] ? rwlock_bug.part.0+0x90/0x90
[ 46.632347][ T7] worker_thread+0x95/0xe00
[ 46.632832][ T7] ? __kthread_parkme+0x115/0x1e0
[ 46.633393][ T7] ? process_one_work+0x1460/0x1460
[ 46.633957][ T7] kthread+0x3a1/0x480
[ 46.634369][ T7] ? set_kthread_struct+0x120/0x120
[ 46.634933][ T7] ret_from_fork+0x1f/0x30
[ 46.635431][ T7]
[ 46.635687][ T7] Allocated by task 7:
[ 46.636151][ T7] kasan_save_stack+0x1b/0x40
[ 46.636628][ T7] __kasan_kmalloc+0x7c/0x90
[ 46.637108][ T7] kmem_cache_alloc_trace+0x19e/0x330
[ 46.637696][ T7] brcmf_cfg80211_attach+0x4a0/0x4040
[ 46.638275][ T7] brcmf_attach+0x389/0xd40
[ 46.638739][ T7] brcmf_usb_probe+0x12de/0x1690
[ 46.639279][ T7] usb_probe_interface+0x2aa/0x760
[ 46.639820][ T7] really_probe+0x205/0xb70
[ 46.640342][ T7] __driver_probe_device+0
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix UBSAN shift-out-of-bounds warning
If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
doing a shift operation where the number of bits shifted equals
number of bits in the operand. This behaviour is undefined.
Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
count is >= number of bits in the operand.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472 |
| Out-of-bounds Read vulnerability in Apache NimBLE HCI H4 driver. Specially crafted HCI event could lead to invalid memory read in H4 driver.
This issue affects Apache NimBLE: through 1.8.
This issue requires a broken or bogus Bluetooth controller and thus severity is considered low.
Users are recommended to upgrade to version 1.9, which fixes the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport
[Why]
Potential out of bounds access in dml2_calculate_rq_and_dlg_params()
because the value of out_lowest_state_idx used as an index for FCLKChangeSupport
array can be greater than 1.
[How]
Currently dml2 core specifies identical values for all FCLKChangeSupport
elements. Always use index 0 in the condition to avoid out of bounds access. |
| A heap buffer over-read vulnerability exists in the wolfSSH_CleanPath() function in wolfSSH. An authenticated remote attacker can trigger the issue via crafted SCP path input containing '/./' sequences, resulting in a heap over read by 1 byte. |
| In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix out-of-bounds in parse_sec_desc()
If osidoffset, gsidoffset and dacloffset could be greater than smb_ntsd
struct size. If it is smaller, It could cause slab-out-of-bounds.
And when validating sid, It need to check it included subauth array size. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: fix out-of-bounds read during lookup
lookup and resize can run in parallel.
The xfrm_state_hash_generation seqlock ensures a retry, but the hash
functions can observe a hmask value that is too large for the new hlist
array.
rehash does:
rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..]
net->xfrm.state_hmask = nhashmask;
While state lookup does:
h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);
hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {
This is only safe in case the update to state_bydst is larger than
net->xfrm.xfrm_state_hmask (or if the lookup function gets
serialized via state spinlock again).
Fix this by prefetching state_hmask and the associated pointers.
The xfrm_state_hash_generation seqlock retry will ensure that the pointer
and the hmask will be consistent.
The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,
add lockdep assertions to document that they are only safe for insert
side.
xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.
AFAICS this is an oversight from back when state lookup was converted to
RCU, this lock should be replaced with RCU in a future patch. |
| Out-of-bounds Read vulnerability in Mitsubishi Electric GENESIS64 versions 10.97 to 10.97.1, Mitsubishi Electric Iconics Digital Solutions GENESIS64 versions 10.97 to 10.97.1, Mitsubishi Electric ICONICS Suite versions 10.97 to 10.97.1, Mitsubishi Electric Iconics Digital Solutions ICONICS Suite versions 10.97 to 10.97.1, Mitsubishi Electric GENESIS32 versions 9.7 and prior, Mitsubishi Electric Iconics Digital Solutions GENESIS32 versions 9.7 and prior, and Mitsubishi Electric MC Works64 versions 4.04E and prior allows a remote unauthenticated attacker to disclose information on memory or cause a Denial of Service (DoS) condition by sending specially crafted packets to the GENESIS64, ICONICS Suite, GENESIS32, or MC Works64 server. |
| An information disclosure vulnerability exists in multiple WSO2 products due to improper implementation of the enrich mediator. Authenticated users may be able to view unintended business data from other mediation contexts because the internal state is not properly isolated or cleared between executions.
This vulnerability does not impact user credentials or access tokens but may lead to leakage of sensitive business information handled during message flows. |
| In PHP versions:8.1.* before 8.1.34, 8.2.* before 8.2.30, 8.3.* before 8.3.29, 8.4.* before 8.4.16, 8.5.* before 8.5.1, the getimagesize() function may leak uninitialized heap memory into the APPn segments (e.g., APP1) when reading images in multi-chunk mode (such as via php://filter). This occurs due to a bug in php_read_stream_all_chunks() that overwrites the buffer without advancing the pointer, leaving tail bytes uninitialized. This may lead to information disclosure of sensitive heap data and affect the confidentiality of the target server. |
| A weakness has been identified in QuickJS up to eb2c89087def1829ed99630cb14b549d7a98408c. This affects the function js_array_buffer_slice of the file quickjs.c. This manipulation causes buffer over-read. The attack is restricted to local execution. The exploit has been made available to the public and could be exploited. This product adopts a rolling release strategy to maintain continuous delivery Patch name: c6fe5a98fd3ef3b7064e6e0145dfebfe12449fea. To fix this issue, it is recommended to deploy a patch. |
| Buffer Over-read vulnerability in Mitsubishi Electric MC Works64 versions 4.00A to 4.04E, Mitsubishi Electric GENESIS64 versions 10.97 and prior, Mitsubishi Electric Iconics Digital Solutions GENESIS64 versions 10.97 and prior, Mitsubishi Electric ICONICS Suite versions 10.97 and prior, Mitsubishi Electric Iconics Digital Solutions ICONICS Suite versions 10.97 and prior, Mitsubishi Electric GENESIS32 versions 9.7 and prior, and Mitsubishi Electric Iconics Digital Solutions GENESIS32 versions 9.7 and prior allows an attacker to cause a DoS condition in the database server by getting a legitimate user to import a configuration file containing specially crafted stored procedures into GENESIS64, ICONICS Suite, MC Works64, or GENESIS32 and execute commands against the database from GENESIS64, ICONICS Suite, MC Works64, or GENESIS32. |
| A vulnerability has been identified in the libarchive library. This flaw can be triggered when file streams are piped into bsdtar, potentially allowing for reading past the end of the file. This out-of-bounds read can lead to unintended consequences, including unpredictable program behavior, memory corruption, or a denial-of-service condition. |
| An out-of-bounds read vulnerability exists in the RLECodec::DecodeByStreams functionality of Grassroot DICOM 3.024. A specially crafted DICOM file can lead to leaking heap data. An attacker can provide a malicious file to trigger this vulnerability. |
