| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The device is deployed with weak and publicly known default passwords for certain hidden user levels, increasing the risk of unauthorized access. This represents a high risk to the integrity of the system. |
| The AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define cloud infrastructure in code and provision it through AWS CloudFormation. Users who use IAM OIDC custom resource provider package will download CA Thumbprints as part of the custom resource workflow. However, the current `tls.connect` method will always set `rejectUnauthorized: false` which is a potential security concern. CDK should follow the best practice and set `rejectUnauthorized: true`. However, this could be a breaking change for existing CDK applications and we should fix this with a feature flag. Note that this is marked as low severity Security advisory because the issuer url is provided by CDK users who define the CDK application. If they insist on connecting to a unauthorized OIDC provider, CDK should not disallow this. Additionally, the code block is run in a Lambda environment which mitigate the MITM attack. The patch is in progress. To mitigate, upgrade to CDK v2.177.0 (Expected release date 2025-02-22). Once upgraded, users should make sure the feature flag '@aws-cdk/aws-iam:oidcRejectUnauthorizedConnections' is set to true in `cdk.context.json` or `cdk.json`. There are no known workarounds for this vulnerability. |
| Arbitrary file deletion vulnerability have been identified in a system function of mobility conductors running AOS-8 operating system. Successful exploitation of this vulnerability could allow an unauthenticated remote malicious actor to delete arbitrary files within the affected system and potentially result in denial-of-service conditions on affected devices. |
| Weblate is a web based localization tool. Prior to 5.15.2, the screenshot images were served directly by the HTTP server without proper access control. This could allow an unauthenticated user to access screenshots after guessing their filename. This vulnerability is fixed in 5.15.2. |
| A stack buffer overflow was found in Internationl components for unicode (ICU ). While running the genrb binary, the 'subtag' struct overflowed at the SRBRoot::addTag function. This issue may lead to memory corruption and local arbitrary code execution. |
| urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length,
enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the
fields in the descriptor. |
| In the Linux kernel, the following vulnerability has been resolved:
fs: writeback: fix use-after-free in __mark_inode_dirty()
An use-after-free issue occurred when __mark_inode_dirty() get the
bdi_writeback that was in the progress of switching.
CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1
......
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __mark_inode_dirty+0x124/0x418
lr : __mark_inode_dirty+0x118/0x418
sp : ffffffc08c9dbbc0
........
Call trace:
__mark_inode_dirty+0x124/0x418
generic_update_time+0x4c/0x60
file_modified+0xcc/0xd0
ext4_buffered_write_iter+0x58/0x124
ext4_file_write_iter+0x54/0x704
vfs_write+0x1c0/0x308
ksys_write+0x74/0x10c
__arm64_sys_write+0x1c/0x28
invoke_syscall+0x48/0x114
el0_svc_common.constprop.0+0xc0/0xe0
do_el0_svc+0x1c/0x28
el0_svc+0x40/0xe4
el0t_64_sync_handler+0x120/0x12c
el0t_64_sync+0x194/0x198
Root cause is:
systemd-random-seed kworker
----------------------------------------------------------------------
___mark_inode_dirty inode_switch_wbs_work_fn
spin_lock(&inode->i_lock);
inode_attach_wb
locked_inode_to_wb_and_lock_list
get inode->i_wb
spin_unlock(&inode->i_lock);
spin_lock(&wb->list_lock)
spin_lock(&inode->i_lock)
inode_io_list_move_locked
spin_unlock(&wb->list_lock)
spin_unlock(&inode->i_lock)
spin_lock(&old_wb->list_lock)
inode_do_switch_wbs
spin_lock(&inode->i_lock)
inode->i_wb = new_wb
spin_unlock(&inode->i_lock)
spin_unlock(&old_wb->list_lock)
wb_put_many(old_wb, nr_switched)
cgwb_release
old wb released
wb_wakeup_delayed() accesses wb,
then trigger the use-after-free
issue
Fix this race condition by holding inode spinlock until
wb_wakeup_delayed() finished. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Initialize the chan_stats array to zero
The adapter->chan_stats[] array is initialized in
mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out
memory. The array is filled in mwifiex_update_chan_statistics()
and then the user can query the data in mwifiex_cfg80211_dump_survey().
There are two potential issues here. What if the user calls
mwifiex_cfg80211_dump_survey() before the data has been filled in.
Also the mwifiex_update_chan_statistics() function doesn't necessarily
initialize the whole array. Since the array was not initialized at
the start that could result in an information leak.
Also this array is pretty small. It's a maximum of 900 bytes so it's
more appropriate to use kcalloc() instead vmalloc(). |
| fluidsynth-2.4.6 and earlier versions is vulnerable to Null pointer dereference in fluid_synth_monopoly.c, that can be triggered when loading an invalid midi file. |
| In the Linux kernel, the following vulnerability has been resolved:
fs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:1965:6
index -84 is out of range for type 's8[341]' (aka 'signed char[341]')
CPU: 1 PID: 4995 Comm: syz-executor146 Not tainted 6.4.0-rc6-syzkaller-00037-gb6dad5178cea #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
dbAllocDmapLev+0x3e5/0x430 fs/jfs/jfs_dmap.c:1965
dbAllocCtl+0x113/0x920 fs/jfs/jfs_dmap.c:1809
dbAllocAG+0x28f/0x10b0 fs/jfs/jfs_dmap.c:1350
dbAlloc+0x658/0xca0 fs/jfs/jfs_dmap.c:874
dtSplitUp fs/jfs/jfs_dtree.c:974 [inline]
dtInsert+0xda7/0x6b00 fs/jfs/jfs_dtree.c:863
jfs_create+0x7b6/0xbb0 fs/jfs/namei.c:137
lookup_open fs/namei.c:3492 [inline]
open_last_lookups fs/namei.c:3560 [inline]
path_openat+0x13df/0x3170 fs/namei.c:3788
do_filp_open+0x234/0x490 fs/namei.c:3818
do_sys_openat2+0x13f/0x500 fs/open.c:1356
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x247/0x290 fs/open.c:1383
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f1f4e33f7e9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc21129578 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1f4e33f7e9
RDX: 000000000000275a RSI: 0000000020000040 RDI: 00000000ffffff9c
RBP: 00007f1f4e2ff080 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f1f4e2ff110
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
The bug occurs when the dbAllocDmapLev()function attempts to access
dp->tree.stree[leafidx + LEAFIND] while the leafidx value is negative.
To rectify this, the patch introduces a safeguard within the
dbAllocDmapLev() function. A check has been added to verify if leafidx is
negative. If it is, the function immediately returns an I/O error, preventing
any further execution that could potentially cause harm.
Tested via syzbot. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix slab-use-after-free in decode_session6
When the xfrm device is set to the qdisc of the sfb type, the cb field
of the sent skb may be modified during enqueuing. Then,
slab-use-after-free may occur when the xfrm device sends IPv6 packets.
The stack information is as follows:
BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890
Read of size 1 at addr ffff8881111458ef by task swapper/3/0
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl+0xd9/0x150
print_address_description.constprop.0+0x2c/0x3c0
kasan_report+0x11d/0x130
decode_session6+0x103f/0x1890
__xfrm_decode_session+0x54/0xb0
xfrmi_xmit+0x173/0x1ca0
dev_hard_start_xmit+0x187/0x700
sch_direct_xmit+0x1a3/0xc30
__qdisc_run+0x510/0x17a0
__dev_queue_xmit+0x2215/0x3b10
neigh_connected_output+0x3c2/0x550
ip6_finish_output2+0x55a/0x1550
ip6_finish_output+0x6b9/0x1270
ip6_output+0x1f1/0x540
ndisc_send_skb+0xa63/0x1890
ndisc_send_rs+0x132/0x6f0
addrconf_rs_timer+0x3f1/0x870
call_timer_fn+0x1a0/0x580
expire_timers+0x29b/0x4b0
run_timer_softirq+0x326/0x910
__do_softirq+0x1d4/0x905
irq_exit_rcu+0xb7/0x120
sysvec_apic_timer_interrupt+0x97/0xc0
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20
RIP: 0010:intel_idle_hlt+0x23/0x30
Code: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 <fa> 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4
RSP: 0018:ffffc90000197d78 EFLAGS: 00000246
RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5
RDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50
RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9d
R10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001
R13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000
cpuidle_enter_state+0xd3/0x6f0
cpuidle_enter+0x4e/0xa0
do_idle+0x2fe/0x3c0
cpu_startup_entry+0x18/0x20
start_secondary+0x200/0x290
secondary_startup_64_no_verify+0x167/0x16b
</TASK>
Allocated by task 939:
kasan_save_stack+0x22/0x40
kasan_set_track+0x25/0x30
__kasan_slab_alloc+0x7f/0x90
kmem_cache_alloc_node+0x1cd/0x410
kmalloc_reserve+0x165/0x270
__alloc_skb+0x129/0x330
inet6_ifa_notify+0x118/0x230
__ipv6_ifa_notify+0x177/0xbe0
addrconf_dad_completed+0x133/0xe00
addrconf_dad_work+0x764/0x1390
process_one_work+0xa32/0x16f0
worker_thread+0x67d/0x10c0
kthread+0x344/0x440
ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff888111145800
which belongs to the cache skbuff_small_head of size 640
The buggy address is located 239 bytes inside of
freed 640-byte region [ffff888111145800, ffff888111145a80)
As commit f855691975bb ("xfrm6: Fix the nexthdr offset in
_decode_session6.") showed, xfrm_decode_session was originally intended
only for the receive path. IP6CB(skb)->nhoff is not set during
transmission. Therefore, set the cb field in the skb to 0 before
sending packets. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Properly order ib_device_unalloc() to avoid UAF
ib_dealloc_device() should be called only after device cleanup. Fix the
dealloc sequence. |
| In the Linux kernel, the following vulnerability has been resolved:
udf: Do not bother merging very long extents
When merging very long extents we try to push as much length as possible
to the first extent. However this is unnecessarily complicated and not
really worth the trouble. Furthermore there was a bug in the logic
resulting in corrupting extents in the file as syzbot reproducer shows.
So just don't bother with the merging of extents that are too long
together. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Unregister devlink params in case interface is down
Currently, in case an interface is down, mlx5 driver doesn't
unregister its devlink params, which leads to this WARN[1].
Fix it by unregistering devlink params in that case as well.
[1]
[ 295.244769 ] WARNING: CPU: 15 PID: 1 at net/core/devlink.c:9042 devlink_free+0x174/0x1fc
[ 295.488379 ] CPU: 15 PID: 1 Comm: shutdown Tainted: G S OE 5.15.0-1017.19.3.g0677e61-bluefield #g0677e61
[ 295.509330 ] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.2.0.12761 Jun 6 2023
[ 295.543096 ] pc : devlink_free+0x174/0x1fc
[ 295.551104 ] lr : mlx5_devlink_free+0x18/0x2c [mlx5_core]
[ 295.561816 ] sp : ffff80000809b850
[ 295.711155 ] Call trace:
[ 295.716030 ] devlink_free+0x174/0x1fc
[ 295.723346 ] mlx5_devlink_free+0x18/0x2c [mlx5_core]
[ 295.733351 ] mlx5_sf_dev_remove+0x98/0xb0 [mlx5_core]
[ 295.743534 ] auxiliary_bus_remove+0x2c/0x50
[ 295.751893 ] __device_release_driver+0x19c/0x280
[ 295.761120 ] device_release_driver+0x34/0x50
[ 295.769649 ] bus_remove_device+0xdc/0x170
[ 295.777656 ] device_del+0x17c/0x3a4
[ 295.784620 ] mlx5_sf_dev_remove+0x28/0xf0 [mlx5_core]
[ 295.794800 ] mlx5_sf_dev_table_destroy+0x98/0x110 [mlx5_core]
[ 295.806375 ] mlx5_unload+0x34/0xd0 [mlx5_core]
[ 295.815339 ] mlx5_unload_one+0x70/0xe4 [mlx5_core]
[ 295.824998 ] shutdown+0xb0/0xd8 [mlx5_core]
[ 295.833439 ] pci_device_shutdown+0x3c/0xa0
[ 295.841651 ] device_shutdown+0x170/0x340
[ 295.849486 ] __do_sys_reboot+0x1f4/0x2a0
[ 295.857322 ] __arm64_sys_reboot+0x2c/0x40
[ 295.865329 ] invoke_syscall+0x78/0x100
[ 295.872817 ] el0_svc_common.constprop.0+0x54/0x184
[ 295.882392 ] do_el0_svc+0x30/0xac
[ 295.889008 ] el0_svc+0x48/0x160
[ 295.895278 ] el0t_64_sync_handler+0xa4/0x130
[ 295.903807 ] el0t_64_sync+0x1a4/0x1a8
[ 295.911120 ] ---[ end trace 4f1d2381d00d9dce ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
ublk: fail to start device if queue setup is interrupted
In ublk_ctrl_start_dev(), if wait_for_completion_interruptible() is
interrupted by signal, queues aren't setup successfully yet, so we
have to fail UBLK_CMD_START_DEV, otherwise kernel oops can be triggered.
Reported by German when working on qemu-storage-deamon which requires
single thread ublk daemon. |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in ThemeGoods Photography photography allows Reflected XSS.This issue affects Photography: from n/a through <= 7.7.2. |
| Deserialization of Untrusted Data vulnerability in ThemeGoods Photography.This issue affects Photography: from n/a through 7.5.2. |
| An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on SRX Series and NFX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).
If an affected device receives specific valid traffic destined to the device, it will cause the PFE to crash and restart. Continued receipt and processing of this traffic will create a sustained DoS condition.
This issue affects Junos OS on SRX Series:
* 21.4 versions before 21.4R3-S7.9,
* 22.1 versions before 22.1R3-S5.3,
* 22.2 versions before 22.2R3-S4.11,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R3.
This issue affects Junos OS on NFX Series:
* 21.4 versions before 21.4R3-S8,
* 22.1 versions after 22.1R1,
* 22.2 versions before 22.2R3-S5,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R3.
Junos OS versions prior to 21.4R1 are not affected by this issue. |
| Missing Authorization vulnerability in ThemeGoods Grand Restaurant WordPress allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Grand Restaurant WordPress: from n/a through 7.0. |
