| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent
A user is able to configure an arbitrary number of rx queues when
creating an interface via netlink. This doesn't work for child PKEY
interfaces because the child interface uses the parent receive channels.
Although the child shares the parent's receive channels, the number of
rx queues is important for the channel_stats array: the parent's rx
channel index is used to access the child's channel_stats. So the array
has to be at least as large as the parent's rx queue size for the
counting to work correctly and to prevent out of bound accesses.
This patch checks for the mentioned scenario and returns an error when
trying to create the interface. The error is propagated to the user. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: change DMA direction while mapping reinjected packets
For fragmented packets, ath12k reassembles each fragment as a normal
packet and then reinjects it into HW ring. In this case, the DMA
direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE. Otherwise,
an invalid payload may be reinjected into the HW and
subsequently delivered to the host.
Given that arbitrary memory can be allocated to the skb buffer,
knowledge about the data contained in the reinjected buffer is lacking.
Consequently, there’s a risk of private information being leaked.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1 |
| In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_erp: Fix object nesting warning
ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM
(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can
contain more ACLs (i.e., tc filters), but the number of masks in each
region (i.e., tc chain) is limited.
In order to mitigate the effects of the above limitation, the device
allows filters to share a single mask if their masks only differ in up
to 8 consecutive bits. For example, dst_ip/25 can be represented using
dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the
number of masks being used (and therefore does not support mask
aggregation), but can contain a limited number of filters.
The driver uses the "objagg" library to perform the mask aggregation by
passing it objects that consist of the filter's mask and whether the
filter is to be inserted into the A-TCAM or the C-TCAM since filters in
different TCAMs cannot share a mask.
The set of created objects is dependent on the insertion order of the
filters and is not necessarily optimal. Therefore, the driver will
periodically ask the library to compute a more optimal set ("hints") by
looking at all the existing objects.
When the library asks the driver whether two objects can be aggregated
the driver only compares the provided masks and ignores the A-TCAM /
C-TCAM indication. This is the right thing to do since the goal is to
move as many filters as possible to the A-TCAM. The driver also forbids
two identical masks from being aggregated since this can only happen if
one was intentionally put in the C-TCAM to avoid a conflict in the
A-TCAM.
The above can result in the following set of hints:
H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta
H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta
After getting the hints from the library the driver will start migrating
filters from one region to another while consulting the computed hints
and instructing the device to perform a lookup in both regions during
the transition.
Assuming a filter with mask X is being migrated into the A-TCAM in the
new region, the hints lookup will return H1. Since H2 is the parent of
H1, the library will try to find the object associated with it and
create it if necessary in which case another hints lookup (recursive)
will be performed. This hints lookup for {mask Y, A-TCAM} will either
return H2 or H3 since the driver passes the library an object comparison
function that ignores the A-TCAM / C-TCAM indication.
This can eventually lead to nested objects which are not supported by
the library [1].
Fix by removing the object comparison function from both the driver and
the library as the driver was the only user. That way the lookup will
only return exact matches.
I do not have a reliable reproducer that can reproduce the issue in a
timely manner, but before the fix the issue would reproduce in several
minutes and with the fix it does not reproduce in over an hour.
Note that the current usefulness of the hints is limited because they
include the C-TCAM indication and represent aggregation that cannot
actually happen. This will be addressed in net-next.
[1]
WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0
Modules linked in:
CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42
Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0
[...]
Call Trace:
<TASK>
__objagg_obj_get+0x2bb/0x580
objagg_obj_get+0xe/0x80
mlxsw_sp_acl_erp_mask_get+0xb5/0xf0
mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0
mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270
mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510
process_one_work+0x151/0x370 |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: Fix input error path memory access
When there is a misconfiguration of input state slow path
KASAN report error. Fix this error.
west login:
[ 52.987278] eth1: renamed from veth11
[ 53.078814] eth1: renamed from veth21
[ 53.181355] eth1: renamed from veth31
[ 54.921702] ==================================================================
[ 54.922602] BUG: KASAN: wild-memory-access in xfrmi_rcv_cb+0x2d/0x295
[ 54.923393] Read of size 8 at addr 6b6b6b6b00000000 by task ping/512
[ 54.924169]
[ 54.924386] CPU: 0 PID: 512 Comm: ping Not tainted 6.9.0-08574-gcd29a4313a1b #25
[ 54.925290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 54.926401] Call Trace:
[ 54.926731] <IRQ>
[ 54.927009] dump_stack_lvl+0x2a/0x3b
[ 54.927478] kasan_report+0x84/0xa6
[ 54.927930] ? xfrmi_rcv_cb+0x2d/0x295
[ 54.928410] xfrmi_rcv_cb+0x2d/0x295
[ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e
[ 54.929354] xfrm4_rcv_cb+0x46/0x5e
[ 54.929804] xfrm_rcv_cb+0x7e/0xa1
[ 54.930240] xfrm_input+0x1b3a/0x1b96
[ 54.930715] ? xfrm_offload+0x41/0x41
[ 54.931182] ? raw_rcv+0x292/0x292
[ 54.931617] ? nf_conntrack_confirm+0xa2/0xa2
[ 54.932158] ? skb_sec_path+0xd/0x3f
[ 54.932610] ? xfrmi_input+0x90/0xce
[ 54.933066] xfrm4_esp_rcv+0x33/0x54
[ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2
[ 54.934089] ip_local_deliver_finish+0x110/0x120
[ 54.934659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2
[ 54.935248] NF_HOOK.constprop.0+0xf8/0x138
[ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68
[ 54.936317] ? secure_tcpv6_ts_off+0x23/0x168
[ 54.936859] ? ip_protocol_deliver_rcu+0x1b2/0x1b2
[ 54.937454] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d
[ 54.938135] NF_HOOK.constprop.0+0xf8/0x138
[ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68
[ 54.939220] ? __xfrm_policy_check2.constprop.0+0x18d/0x18d
[ 54.939904] ? ip_local_deliver_finish+0x120/0x120
[ 54.940497] __netif_receive_skb_one_core+0xc9/0x107
[ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2
[ 54.941771] ? blk_mq_start_stopped_hw_queues+0xc7/0xf9
[ 54.942413] ? blk_mq_start_stopped_hw_queue+0x38/0x38
[ 54.943044] ? virtqueue_get_buf_ctx+0x295/0x46b
[ 54.943618] process_backlog+0xb3/0x187
[ 54.944102] __napi_poll.constprop.0+0x57/0x1a7
[ 54.944669] net_rx_action+0x1cb/0x380
[ 54.945150] ? __napi_poll.constprop.0+0x1a7/0x1a7
[ 54.945744] ? vring_new_virtqueue+0x17a/0x17a
[ 54.946300] ? note_interrupt+0x2cd/0x367
[ 54.946805] handle_softirqs+0x13c/0x2c9
[ 54.947300] do_softirq+0x5f/0x7d
[ 54.947727] </IRQ>
[ 54.948014] <TASK>
[ 54.948300] __local_bh_enable_ip+0x48/0x62
[ 54.948832] __neigh_event_send+0x3fd/0x4ca
[ 54.949361] neigh_resolve_output+0x1e/0x210
[ 54.949896] ip_finish_output2+0x4bf/0x4f0
[ 54.950410] ? __ip_finish_output+0x171/0x1b8
[ 54.950956] ip_send_skb+0x25/0x57
[ 54.951390] raw_sendmsg+0xf95/0x10c0
[ 54.951850] ? check_new_pages+0x45/0x71
[ 54.952343] ? raw_hash_sk+0x21b/0x21b
[ 54.952815] ? kernel_init_pages+0x42/0x51
[ 54.953337] ? prep_new_page+0x44/0x51
[ 54.953811] ? get_page_from_freelist+0x72b/0x915
[ 54.954390] ? signal_pending_state+0x77/0x77
[ 54.954936] ? preempt_count_sub+0x14/0xb3
[ 54.955450] ? __might_resched+0x8a/0x240
[ 54.955951] ? __might_sleep+0x25/0xa0
[ 54.956424] ? first_zones_zonelist+0x2c/0x43
[ 54.956977] ? __rcu_read_lock+0x2d/0x3a
[ 54.957476] ? __pte_offset_map+0x32/0xa4
[ 54.957980] ? __might_resched+0x8a/0x240
[ 54.958483] ? __might_sleep+0x25/0xa0
[ 54.958963] ? inet_send_prepare+0x54/0x54
[ 54.959478] ? sock_sendmsg_nosec+0x42/0x6c
[ 54.960000] sock_sendmsg_nosec+0x42/0x6c
[ 54.960502] __sys_sendto+0x15d/0x1cc
[ 54.960966] ? __x64_sys_getpeername+0x44/0x44
[ 54.961522] ? __handle_mm_fault+0x679/0xae4
[ 54.962068] ? find_vma+0x6b/0x
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
media: pci: ivtv: Add check for DMA map result
In case DMA fails, 'dma->SG_length' is 0. This value is later used to
access 'dma->SGarray[dma->SG_length - 1]', which will cause out of
bounds access.
Add check to return early on invalid value. Adjust warnings accordingly.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Clean up error handling in vpci_scan_bus()
Smatch complains about inconsistent NULL checking in vpci_scan_bus():
drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021)
Instead of printing an error message and then crashing we should return
an error code and clean up.
Also the NULL check is reversed so it prints an error for success
instead of failure. |
| In the Linux kernel, the following vulnerability has been resolved:
perf: Fix event leak upon exit
When a task is scheduled out, pending sigtrap deliveries are deferred
to the target task upon resume to userspace via task_work.
However failures while adding an event's callback to the task_work
engine are ignored. And since the last call for events exit happen
after task work is eventually closed, there is a small window during
which pending sigtrap can be queued though ignored, leaking the event
refcount addition such as in the following scenario:
TASK A
-----
do_exit()
exit_task_work(tsk);
<IRQ>
perf_event_overflow()
event->pending_sigtrap = pending_id;
irq_work_queue(&event->pending_irq);
</IRQ>
=========> PREEMPTION: TASK A -> TASK B
event_sched_out()
event->pending_sigtrap = 0;
atomic_long_inc_not_zero(&event->refcount)
// FAILS: task work has exited
task_work_add(&event->pending_task)
[...]
<IRQ WORK>
perf_pending_irq()
// early return: event->oncpu = -1
</IRQ WORK>
[...]
=========> TASK B -> TASK A
perf_event_exit_task(tsk)
perf_event_exit_event()
free_event()
WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1)
// leak event due to unexpected refcount == 2
As a result the event is never released while the task exits.
Fix this with appropriate task_work_add()'s error handling. |
| In the Linux kernel, the following vulnerability has been resolved:
perf: Fix event leak upon exec and file release
The perf pending task work is never waited upon the matching event
release. In the case of a child event, released via free_event()
directly, this can potentially result in a leaked event, such as in the
following scenario that doesn't even require a weak IRQ work
implementation to trigger:
schedule()
prepare_task_switch()
=======> <NMI>
perf_event_overflow()
event->pending_sigtrap = ...
irq_work_queue(&event->pending_irq)
<======= </NMI>
perf_event_task_sched_out()
event_sched_out()
event->pending_sigtrap = 0;
atomic_long_inc_not_zero(&event->refcount)
task_work_add(&event->pending_task)
finish_lock_switch()
=======> <IRQ>
perf_pending_irq()
//do nothing, rely on pending task work
<======= </IRQ>
begin_new_exec()
perf_event_exit_task()
perf_event_exit_event()
// If is child event
free_event()
WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1)
// event is leaked
Similar scenarios can also happen with perf_event_remove_on_exec() or
simply against concurrent perf_event_release().
Fix this with synchonizing against the possibly remaining pending task
work while freeing the event, just like is done with remaining pending
IRQ work. This means that the pending task callback neither need nor
should hold a reference to the event, preventing it from ever beeing
freed. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: prime: fix refcount underflow
Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and
hence the backing ttm_bo) leads to a refcount underflow.
Instead of calling nouveau_bo_ref() in the unwind path of
drm_gem_object_init(), clean things up manually.
(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5) |
| A vulnerability has been found in kidaze CourseSelectionSystem up to 42cd892b40a18d50bd4ed1905fa89f939173a464. Impacted is an unknown function of the file /Profilers/PriProfile/COUNT3s7.php. The manipulation of the argument cbe leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available. |
| A vulnerability was determined in Jinher OA 2.0. The impacted element is an unknown function of the file /c6/Jhsoft.Web.module/ToolBar/ManageWord.aspx/?text=GetUrl&style=1. This manipulation causes xml external entity reference. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. |
| A vulnerability was found in Dibo Data Decision Making System up to 2.7.0. The affected element is the function downloadImpTemplet of the file /common/dep/common_dep.action.jsp. The manipulation of the argument filePath results in path traversal. It is possible to launch the attack remotely. The exploit has been made public and could be used. |
| In the Linux kernel, the following vulnerability has been resolved:
lib: alloc_tag_module_unload must wait for pending kfree_rcu calls
Ben Greear reports following splat:
------------[ cut here ]------------
net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload
WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0
Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat
...
Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020
RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0
codetag_unload_module+0x19b/0x2a0
? codetag_load_module+0x80/0x80
nf_nat module exit calls kfree_rcu on those addresses, but the free
operation is likely still pending by the time alloc_tag checks for leaks.
Wait for outstanding kfree_rcu operations to complete before checking
resolves this warning.
Reproducer:
unshare -n iptables-nft -t nat -A PREROUTING -p tcp
grep nf_nat /proc/allocinfo # will list 4 allocations
rmmod nft_chain_nat
rmmod nf_nat # will WARN.
[akpm@linux-foundation.org: add comment] |
| In the Linux kernel, the following vulnerability has been resolved:
net: phy: Fix missing of_node_put() for leds
The call of of_get_child_by_name() will cause refcount incremented
for leds, if it succeeds, it should call of_node_put() to decrease
it, fix it. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: add check for invalid name in btf_name_valid_section()
If the length of the name string is 1 and the value of name[0] is NULL
byte, an OOB vulnerability occurs in btf_name_valid_section() and the
return value is true, so the invalid name passes the check.
To solve this, you need to check if the first position is NULL byte and
if the first character is printable. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle errors from btrfs_dec_ref() properly
In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This is
incorrect, we have proper error handling here, return the error. |
| In DOXENSE WATCHDOC before 6.1.1.5332, Deserialization of Untrusted Data can lead to remote code execution through the .NET Remoting library in the Watchdoc administration interface. |
| A vulnerability exists in the 'dagre-d3-es' Node.js package version 7.0.9, specifically within the 'bk' module's addConflict function, which fails to properly sanitize user-supplied input during property assignment operations. This flaw allows attackers to exploit prototype pollution vulnerabilities by injecting malicious input values (e.g., "__proto__"), enabling unauthorized modification of the JavaScript Object prototype chain. Successful exploitation could lead to denial of service conditions, unexpected application behavior, or potential execution of arbitrary code in contexts where polluted properties are later accessed or executed. The issue affects versions prior to 7.0.11 and remains unpatched at the time of disclosure. |
| web3-core-method is a package designed to creates the methods on the web3 modules. A Prototype Pollution vulnerability in the attachToObject function of web3-core-method version 1.10.4 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence. |
| spmrc is a package that provides the rc manager for spm. A Prototype Pollution vulnerability in the set and config function of spmrc version 1.2.0 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence. |
