| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Skip Rx TID cleanup for self peer
During peer create, dp setup for the peer is done where Rx TID is
updated for all the TIDs. Peer object for self peer will not go through
dp setup.
When core halts, dp cleanup is done for all the peers. While cleanup,
rx_tid::ab is accessed which causes below stack trace for self peer.
WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851
Call Trace:
__warn+0x7b/0x1a0
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
report_bug+0x10b/0x200
handle_bug+0x3f/0x70
exc_invalid_op+0x13/0x60
asm_exc_invalid_op+0x16/0x20
ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]
ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k]
ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k]
ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k]
ath12k_core_halt+0x3b/0x100 [ath12k]
ath12k_core_reset+0x494/0x4c0 [ath12k]
sta object in peer will be updated when remote peer is created. Hence
use peer::sta to detect the self peer and skip the cleanup.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in `struct
mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------
[ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)
[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network
this device was connected to. The source of the warning looks like:
ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[i].ssid, ssid_len);
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this
struct, but it already didn't account for the size of the one-element
array, so it doesn't need to be changed. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: hyperv: streamline driver probe to avoid devres issues
It was found that unloading 'hid_hyperv' module results in a devres
complaint:
...
hv_vmbus: unregistering driver hid_hyperv
------------[ cut here ]------------
WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0
...
Call Trace:
<TASK>
? devres_release_group+0x1f2/0x2c0
? __warn+0xd1/0x1c0
? devres_release_group+0x1f2/0x2c0
? report_bug+0x32a/0x3c0
? handle_bug+0x53/0xa0
? exc_invalid_op+0x18/0x50
? asm_exc_invalid_op+0x1a/0x20
? devres_release_group+0x1f2/0x2c0
? devres_release_group+0x90/0x2c0
? rcu_is_watching+0x15/0xb0
? __pfx_devres_release_group+0x10/0x10
hid_device_remove+0xf5/0x220
device_release_driver_internal+0x371/0x540
? klist_put+0xf3/0x170
bus_remove_device+0x1f1/0x3f0
device_del+0x33f/0x8c0
? __pfx_device_del+0x10/0x10
? cleanup_srcu_struct+0x337/0x500
hid_destroy_device+0xc8/0x130
mousevsc_remove+0xd2/0x1d0 [hid_hyperv]
device_release_driver_internal+0x371/0x540
driver_detach+0xc5/0x180
bus_remove_driver+0x11e/0x2a0
? __mutex_unlock_slowpath+0x160/0x5e0
vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]
...
And the issue seems to be that the corresponding devres group is not
allocated. Normally, devres_open_group() is called from
__hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver'
with 'mousevsc_hid_driver' stub and basically re-implements
__hid_device_probe() by calling hid_parse() and hid_hw_start() but not
devres_open_group(). hid_device_probe() does not call __hid_device_probe()
for it. Later, when the driver is removed, hid_device_remove() calls
devres_release_group() as it doesn't check whether hdev->driver was
initially overridden or not.
The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure
timely release of driver-allocated resources") but the commit itself seems
to be correct.
Fix the issue by dropping the 'hid_dev->driver' override and using
hid_register_driver()/hid_unregister_driver() instead. Alternatively, it
would have been possible to rely on the default handling but
HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work
for mousevsc as-is. |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: Free skb when TX metadata options are invalid
When a new skb is allocated for transmitting an xsk descriptor, i.e., for
every non-multibuf descriptor or the first frag of a multibuf descriptor,
but the descriptor is later found to have invalid options set for the TX
metadata, the new skb is never freed. This can leak skbs until the send
buffer is full which makes sending more packets impossible.
Fix this by freeing the skb in the error path if we are currently dealing
with the first frag, i.e., an skb allocated in this iteration of
xsk_build_skb. |
| Vulnerability in the melis-core module of Melis Technology's Melis Platform, which, if exploited, allows an unauthenticated attacker to create an administrator account via a request to '/melis/MelisCore/ToolUser/addNewUser'. |
| In the Linux kernel, the following vulnerability has been resolved:
erofs: handle NONHEAD !delta[1] lclusters gracefully
syzbot reported a WARNING in iomap_iter_done:
iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80
ioctl_fiemap fs/ioctl.c:220 [inline]
Generally, NONHEAD lclusters won't have delta[1]==0, except for crafted
images and filesystems created by pre-1.0 mkfs versions.
Previously, it would immediately bail out if delta[1]==0, which led to
inadequate decompressed lengths (thus FIEMAP is impacted). Treat it as
delta[1]=1 to work around these legacy mkfs versions.
`lclusterbits > 14` is illegal for compact indexes, error out too. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix the qp flush warnings in req
When the qp is in error state, the status of WQEs in the queue should be
set to error. Or else the following will appear.
[ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe]
[ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6
[ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65
[ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe]
[ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24
[ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246
[ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008
[ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac
[ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450
[ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800
[ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000
[ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000
[ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0
[ 920.623680] Call Trace:
[ 920.623815] <TASK>
[ 920.623933] ? __warn+0x79/0xc0
[ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe]
[ 920.624356] ? report_bug+0xfb/0x150
[ 920.624594] ? handle_bug+0x3c/0x60
[ 920.624796] ? exc_invalid_op+0x14/0x70
[ 920.624976] ? asm_exc_invalid_op+0x16/0x20
[ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe]
[ 920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe]
[ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe]
[ 920.626037] rxe_requester+0x625/0xde0 [rdma_rxe]
[ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe]
[ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe]
[ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe]
[ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe]
[ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120
[ 920.627522] handle_softirqs+0xc2/0x250
[ 920.627728] ? sort_range+0x20/0x20
[ 920.627942] run_ksoftirqd+0x1f/0x30
[ 920.628158] smpboot_thread_fn+0xc7/0x1b0
[ 920.628334] kthread+0xd6/0x100
[ 920.628504] ? kthread_complete_and_exit+0x20/0x20
[ 920.628709] ret_from_fork+0x1f/0x30
[ 920.628892] </TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs
Base clocks are the first in being probed and are real dependencies of the
rest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880,
RT305x and RT3883 'xtal' must be defined first since in any other case,
when fixed clocks are probed they are delayed until 'xtal' is probed so the
following warning appears:
WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0
Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000
80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000
00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000
203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009
00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000
...
Call Trace:
[<800065d0>] show_stack+0x64/0xf4
[<804bca14>] dump_stack_lvl+0x38/0x60
[<800218ac>] __warn+0x94/0xe4
[<8002195c>] warn_slowpath_fmt+0x60/0x94
[<80259ff8>] rt3883_bus_recalc_rate+0x98/0x138
[<80254530>] __clk_register+0x568/0x688
[<80254838>] of_clk_hw_register+0x18/0x2c
[<8070b910>] rt2880_clk_of_clk_init_driver+0x18c/0x594
[<8070b628>] of_clk_init+0x1c0/0x23c
[<806fc448>] plat_time_init+0x58/0x18c
[<806fdaf0>] time_init+0x10/0x6c
[<806f9bc4>] start_kernel+0x458/0x67c
---[ end trace 0000000000000000 ]---
When this driver was mainlined we could not find any active users of old
ralink SoCs so we cannot perform any real tests for them. Now, one user
of a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and
reported some issues in openWRT:
- https://github.com/openwrt/openwrt/issues/16054
Thus, define a 'rt2880_xtal_recalc_rate()' just returning the expected
frequency 40Mhz and use it along the old ralink SoCs to have a correct
boot trace with no warnings and a working clock plan from the beggining. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix atomic calls in ath12k_mac_op_set_bitrate_mask()
When I try to manually set bitrates:
iw wlan0 set bitrates legacy-2.4 1
I get sleeping from invalid context error, see below. Fix that by switching to
use recently introduced ieee80211_iterate_stations_mtx().
Do note that WCN6855 firmware is still crashing, I'm not sure if that firmware
even supports bitrate WMI commands and should we consider disabling
ath12k_mac_op_set_bitrate_mask() for WCN6855? But that's for another patch.
BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath12k/wmi.c:420
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 2236, name: iw
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
3 locks held by iw/2236:
#0: ffffffffabc6f1d8 (cb_lock){++++}-{3:3}, at: genl_rcv+0x14/0x40
#1: ffff888138410810 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: nl80211_pre_doit+0x54d/0x800 [cfg80211]
#2: ffffffffab2cfaa0 (rcu_read_lock){....}-{1:2}, at: ieee80211_iterate_stations_atomic+0x2f/0x200 [mac80211]
CPU: 3 UID: 0 PID: 2236 Comm: iw Not tainted 6.11.0-rc7-wt-ath+ #1772
Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021
Call Trace:
<TASK>
dump_stack_lvl+0xa4/0xe0
dump_stack+0x10/0x20
__might_resched+0x363/0x5a0
? __alloc_skb+0x165/0x340
__might_sleep+0xad/0x160
ath12k_wmi_cmd_send+0xb1/0x3d0 [ath12k]
? ath12k_wmi_init_wcn7850+0xa40/0xa40 [ath12k]
? __netdev_alloc_skb+0x45/0x7b0
? __asan_memset+0x39/0x40
? ath12k_wmi_alloc_skb+0xf0/0x150 [ath12k]
? reacquire_held_locks+0x4d0/0x4d0
ath12k_wmi_set_peer_param+0x340/0x5b0 [ath12k]
ath12k_mac_disable_peer_fixed_rate+0xa3/0x110 [ath12k]
? ath12k_mac_vdev_stop+0x4f0/0x4f0 [ath12k]
ieee80211_iterate_stations_atomic+0xd4/0x200 [mac80211]
ath12k_mac_op_set_bitrate_mask+0x5d2/0x1080 [ath12k]
? ath12k_mac_vif_chan+0x320/0x320 [ath12k]
drv_set_bitrate_mask+0x267/0x470 [mac80211]
ieee80211_set_bitrate_mask+0x4cc/0x8a0 [mac80211]
? __this_cpu_preempt_check+0x13/0x20
nl80211_set_tx_bitrate_mask+0x2bc/0x530 [cfg80211]
? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211]
? trace_contention_end+0xef/0x140
? rtnl_unlock+0x9/0x10
? nl80211_pre_doit+0x557/0x800 [cfg80211]
genl_family_rcv_msg_doit+0x1f0/0x2e0
? genl_family_rcv_msg_attrs_parse.isra.0+0x250/0x250
? ns_capable+0x57/0xd0
genl_family_rcv_msg+0x34c/0x600
? genl_family_rcv_msg_dumpit+0x310/0x310
? __lock_acquire+0xc62/0x1de0
? he_set_mcs_mask.isra.0+0x8d0/0x8d0 [cfg80211]
? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211]
? cfg80211_external_auth_request+0x690/0x690 [cfg80211]
genl_rcv_msg+0xa0/0x130
netlink_rcv_skb+0x14c/0x400
? genl_family_rcv_msg+0x600/0x600
? netlink_ack+0xd70/0xd70
? rwsem_optimistic_spin+0x4f0/0x4f0
? genl_rcv+0x14/0x40
? down_read_killable+0x580/0x580
? netlink_deliver_tap+0x13e/0x350
? __this_cpu_preempt_check+0x13/0x20
genl_rcv+0x23/0x40
netlink_unicast+0x45e/0x790
? netlink_attachskb+0x7f0/0x7f0
netlink_sendmsg+0x7eb/0xdb0
? netlink_unicast+0x790/0x790
? __this_cpu_preempt_check+0x13/0x20
? selinux_socket_sendmsg+0x31/0x40
? netlink_unicast+0x790/0x790
__sock_sendmsg+0xc9/0x160
____sys_sendmsg+0x620/0x990
? kernel_sendmsg+0x30/0x30
? __copy_msghdr+0x410/0x410
? __kasan_check_read+0x11/0x20
? mark_lock+0xe6/0x1470
___sys_sendmsg+0xe9/0x170
? copy_msghdr_from_user+0x120/0x120
? __lock_acquire+0xc62/0x1de0
? do_fault_around+0x2c6/0x4e0
? do_user_addr_fault+0x8c1/0xde0
? reacquire_held_locks+0x220/0x4d0
? do_user_addr_fault+0x8c1/0xde0
? __kasan_check_read+0x11/0x20
? __fdget+0x4e/0x1d0
? sockfd_lookup_light+0x1a/0x170
__sys_sendmsg+0xd2/0x180
? __sys_sendmsg_sock+0x20/0x20
? reacquire_held_locks+0x4d0/0x4d0
? debug_smp_processor_id+0x17/0x20
__x64_sys_sendmsg+0x72/0xb0
? lockdep_hardirqs_on+0x7d/0x100
x64_sys_call+0x894/0x9f0
do_syscall_64+0x64/0x130
entry_SYSCALL_64_after_
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: set the right AMDGPU sg segment limitation
The driver needs to set the correct max_segment_size;
otherwise debug_dma_map_sg() will complain about the
over-mapping of the AMDGPU sg length as following:
WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370
[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd
[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii
[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492
[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021
[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370
[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05
[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286
[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027
[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680
[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930
[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000
[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800
[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000
[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0
[ 364.049605] Call Trace:
[ 364.049607] <TASK>
[ 364.049609] ? show_regs+0x6d/0x80
[ 364.049614] ? __warn+0x8c/0x140
[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370
[ 364.049621] ? report_bug+0x193/0x1a0
[ 364.049627] ? handle_bug+0x46/0x80
[ 364.049631] ? exc_invalid_op+0x1d/0x80
[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30
[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370
[ 364.049647] __dma_map_sg_attrs+0x90/0xe0
[ 364.049651] dma_map_sgtable+0x25/0x40
[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu]
[ 364.049935] ? srso_return_thunk+0x5/0x5f
[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu]
[ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm]
[ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm]
[ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu]
[ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu]
[ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu]
[ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu]
[ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu]
[ 364.05105
---truncated--- |
| A security flaw has been discovered in Rebuild up to 4.1.3. Affected by this issue is some unknown functionality of the component Comment/Guestbook. Performing manipulation results in cross site scripting. It is possible to initiate the attack remotely. Upgrading to version 4.1.4 can resolve this issue. It is suggested to upgrade the affected component. According to the researcher the vendor has confirmed the flaw and fix in a private issue response. |
| ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.) |
| OS Command Injection vulnerability in EndRun Technologies Sonoma D12 Network Time Server (GPS) F/W 6010-0071-000 Ver 4.00 allows attackers to execute arbitrary code, cause a denial of service, gain escalated privileges, and gain sensitive information. |
| A stored Cross-site scripting (XSS) vulnerability exists in the Customer Management Module of LionCoders SalePro POS 5.4.8. An authenticated attacker can inject arbitrary web script or HTML via the 'Customer Name' parameter when creating or editing customer profiles. This malicious input is improperly sanitized before storage and subsequent rendering, leading to script execution in the browsers of users who view the affected customer details. |
| OS Command Injection vulnerability in EndRun Technologies Sonoma D12 Network Time Server (GPS) F/W 6010-0071-000 Ver 4.00 allows attackers to execute arbitrary code, cause a denial of service, gain escalated privileges, and gain sensitive information. |
| Components of the YoSmart YoLink ecosystem through 2025-10-02 leverage unencrypted MQTT to communicate over the internet. An attacker with the ability to monitor network traffic could therefore obtain sensitive information or tamper with the traffic to control affected devices. This affects YoLink Hub 0382, YoLink Mobile Application 1.40.41, and YoLink MQTT Broker. |
| OS Command Injection vulnerability in EndRun Technologies Sonoma D12 Network Time Server (GPS) F/W 6010-0071-000 Ver 4.00 allows attackers to execute arbitrary code, cause a denial of service, gain escalated privileges, and gain sensitive information. |
| The YoSmart YoLink Smart Hub device 0382 exposes a UART debug interface. An attacker with direct physical access can leverage this interface to read a boot log, which includes network access credentials. |
| The YoSmart YoLink application through 2025-10-02 has session tokens with unexpectedly long lifetimes. |
| OS Command Injection vulnerability in EndRun Technologies Sonoma D12 Network Time Server (GPS) F/W 6010-0071-000 Ver 4.00 allows attackers to execute arbitrary code, cause a denial of service, gain escalated privileges, gain sensitive information, and possibly other unspecified impacts. |
