| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Fix accessing freed irq affinity_hint
In stmmac_request_irq_multi_msi(), a pointer to the stack variable
cpu_mask is passed to irq_set_affinity_hint(). This value is stored in
irq_desc->affinity_hint, but once stmmac_request_irq_multi_msi()
returns, the pointer becomes dangling.
The affinity_hint is exposed via procfs with S_IRUGO permissions,
allowing any unprivileged process to read it. Accessing this stale
pointer can lead to:
- a kernel oops or panic if the referenced memory has been released and
unmapped, or
- leakage of kernel data into userspace if the memory is re-used for
other purposes.
All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are
affected. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path
If a shared IRQ is used by the driver due to platform limitation, then the
IRQ affinity hint is set right after the allocation of IRQ vectors in
ath11k_pci_alloc_msi(). This does no harm unless one of the functions
requesting the IRQ fails and attempt to free the IRQ. This results in the
below warning:
WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c
Call trace:
free_irq+0x278/0x29c
ath11k_pcic_free_irq+0x70/0x10c [ath11k]
ath11k_pci_probe+0x800/0x820 [ath11k_pci]
local_pci_probe+0x40/0xbc
The warning is due to not clearing the affinity hint before freeing the
IRQs.
So to fix this issue, clear the IRQ affinity hint before calling
ath11k_pcic_free_irq() in the error path. The affinity will be cleared once
again further down the error path due to code organization, but that does
no harm.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: fix NULL pointer dereference in l3mdev_l3_rcv
When delete l3s ipvlan:
ip link del link eth0 ipvlan1 type ipvlan mode l3s
This may cause a null pointer dereference:
Call trace:
ip_rcv_finish+0x48/0xd0
ip_rcv+0x5c/0x100
__netif_receive_skb_one_core+0x64/0xb0
__netif_receive_skb+0x20/0x80
process_backlog+0xb4/0x204
napi_poll+0xe8/0x294
net_rx_action+0xd8/0x22c
__do_softirq+0x12c/0x354
This is because l3mdev_l3_rcv() visit dev->l3mdev_ops after
ipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process
like this:
(CPU1) | (CPU2)
l3mdev_l3_rcv() |
check dev->priv_flags: |
master = skb->dev; |
|
| ipvlan_l3s_unregister()
| set dev->priv_flags
| dev->l3mdev_ops = NULL;
|
visit master->l3mdev_ops |
To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan. |
| In the Linux kernel, the following vulnerability has been resolved:
net: allow small head cache usage with large MAX_SKB_FRAGS values
Sabrina reported the following splat:
WARNING: CPU: 0 PID: 1 at net/core/dev.c:6935 netif_napi_add_weight_locked+0x8f2/0xba0
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc1-net-00092-g011b03359038 #996
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
RIP: 0010:netif_napi_add_weight_locked+0x8f2/0xba0
Code: e8 c3 e6 6a fe 48 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc c7 44 24 10 ff ff ff ff e9 8f fb ff ff e8 9e e6 6a fe <0f> 0b e9 d3 fe ff ff e8 92 e6 6a fe 48 8b 04 24 be ff ff ff ff 48
RSP: 0000:ffffc9000001fc60 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff88806ce48128 RCX: 1ffff11001664b9e
RDX: ffff888008f00040 RSI: ffffffff8317ca42 RDI: ffff88800b325cb6
RBP: ffff88800b325c40 R08: 0000000000000001 R09: ffffed100167502c
R10: ffff88800b3a8163 R11: 0000000000000000 R12: ffff88800ac1c168
R13: ffff88800ac1c168 R14: ffff88800ac1c168 R15: 0000000000000007
FS: 0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff888008201000 CR3: 0000000004c94001 CR4: 0000000000370ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
gro_cells_init+0x1ba/0x270
xfrm_input_init+0x4b/0x2a0
xfrm_init+0x38/0x50
ip_rt_init+0x2d7/0x350
ip_init+0xf/0x20
inet_init+0x406/0x590
do_one_initcall+0x9d/0x2e0
do_initcalls+0x23b/0x280
kernel_init_freeable+0x445/0x490
kernel_init+0x20/0x1d0
ret_from_fork+0x46/0x80
ret_from_fork_asm+0x1a/0x30
</TASK>
irq event stamp: 584330
hardirqs last enabled at (584338): [<ffffffff8168bf87>] __up_console_sem+0x77/0xb0
hardirqs last disabled at (584345): [<ffffffff8168bf6c>] __up_console_sem+0x5c/0xb0
softirqs last enabled at (583242): [<ffffffff833ee96d>] netlink_insert+0x14d/0x470
softirqs last disabled at (583754): [<ffffffff8317c8cd>] netif_napi_add_weight_locked+0x77d/0xba0
on kernel built with MAX_SKB_FRAGS=45, where SKB_WITH_OVERHEAD(1024)
is smaller than GRO_MAX_HEAD.
Such built additionally contains the revert of the single page frag cache
so that napi_get_frags() ends up using the page frag allocator, triggering
the splat.
Note that the underlying issue is independent from the mentioned
revert; address it ensuring that the small head cache will fit either TCP
and GRO allocation and updating napi_alloc_skb() and __netdev_alloc_skb()
to select kmalloc() usage for any allocation fitting such cache. |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: improve shutdown sequence
Alexander Sverdlin presents 2 problems during shutdown with the
lan9303 driver. One is specific to lan9303 and the other just happens
to reproduce there.
The first problem is that lan9303 is unique among DSA drivers in that it
calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown,
not remove):
phy_state_machine()
-> ...
-> dsa_user_phy_read()
-> ds->ops->phy_read()
-> lan9303_phy_read()
-> chip->ops->phy_read()
-> lan9303_mdio_phy_read()
-> dev_get_drvdata()
But we never stop the phy_state_machine(), so it may continue to run
after dsa_switch_shutdown(). Our common pattern in all DSA drivers is
to set drvdata to NULL to suppress the remove() method that may come
afterwards. But in this case it will result in an NPD.
The second problem is that the way in which we set
dp->conduit->dsa_ptr = NULL; is concurrent with receive packet
processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL,
but afterwards, rather than continuing to use that non-NULL value,
dev->dsa_ptr is dereferenced again and again without NULL checks:
dsa_conduit_find_user() and many other places. In between dereferences,
there is no locking to ensure that what was valid once continues to be
valid.
Both problems have the common aspect that closing the conduit interface
solves them.
In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN
event in dsa_user_netdevice_event() which closes user ports as well.
dsa_port_disable_rt() calls phylink_stop(), which synchronously stops
the phylink state machine, and ds->ops->phy_read() will thus no longer
call into the driver after this point.
In the second case, dev_close(conduit) should do this, as per
Documentation/networking/driver.rst:
| Quiescence
| ----------
|
| After the ndo_stop routine has been called, the hardware must
| not receive or transmit any data. All in flight packets must
| be aborted. If necessary, poll or wait for completion of
| any reset commands.
So it should be sufficient to ensure that later, when we zeroize
conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call
on this conduit.
The addition of the netif_device_detach() function is to ensure that
ioctls, rtnetlinks and ethtool requests on the user ports no longer
propagate down to the driver - we're no longer prepared to handle them.
The race condition actually did not exist when commit 0650bf52b31f
("net: dsa: be compatible with masters which unregister on shutdown")
first introduced dsa_switch_shutdown(). It was created later, when we
stopped unregistering the user interfaces from a bad spot, and we just
replaced that sequence with a racy zeroization of conduit->dsa_ptr
(one which doesn't ensure that the interfaces aren't up). |
| In the Linux kernel, the following vulnerability has been resolved:
cachestat: do not flush stats in recency check
syzbot detects that cachestat() is flushing stats, which can sleep, in its
RCU read section (see [1]). This is done in the workingset_test_recent()
step (which checks if the folio's eviction is recent).
Move the stat flushing step to before the RCU read section of cachestat,
and skip stat flushing during the recency check.
[1]: https://lore.kernel.org/cgroups/[email protected]/ |
| A flaw was found in Smallrye, where smallrye-fault-tolerance is vulnerable to an out-of-memory (OOM) issue. This vulnerability is externally triggered when calling the metrics URI. Every call creates a new object within meterMap and may lead to a denial of service (DoS) issue. |
| Kaspersky has fixed a security issue in Kaspersky Endpoint Security for Linux (any version with anti-virus databases prior to 18.11.2025), Kaspersky Industrial CyberSecurity for Linux Nodes (any version with anti-virus databases prior to 18.11.2025), and Kaspersky Endpoint Security for Mac (12.0.0.325, 12.1.0.553, and 12.2.0.694 with anti-virus databases prior to 18.11.2025) that could have allowed a reflected XSS attack to be carried out by an attacker using phishing techniques. |
| A security flaw has been discovered in Muse Group MuseHub 2.1.0.1567. The affected element is an unknown function of the file C:\Program Files\WindowsApps\Muse.MuseHub_2.1.0.1567_x64__rb9pth70m6nz6\Muse.Updater.exe of the component Windows Service. The manipulation results in unquoted search path. The attack is only possible with local access. A high complexity level is associated with this attack. The exploitability is described as difficult. The vendor was contacted early about this disclosure but did not respond in any way. |
| A bug in the filesystem traversal fallback path causes fs/diriterate/diriterate.go:Next() to overindex an empty slice when ReadDir returns nil for an empty directory, resulting in a panic (index out of range) and an application crash (denial of service) in OSV-SCALIBR. |
| A security vulnerability has been detected in itsourcecode Human Resource Management System 1.0. Impacted is an unknown function of the file /src/store/NoticeStore.php. Such manipulation of the argument noticeDesc leads to sql injection. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. |
| The Looker endpoint for generating new projects from database connections allows users to specify "looker" as a connection name, which is a reserved internal name for Looker's internal MySQL database. The schemas parameter is vulnerable to SQL injection, enabling attackers to manipulate SELECT queries that are constructed and executed against the internal MySQL database. This vulnerability allows users with developer permissions to extract data from Looker's internal MySQL database.
Looker-hosted and Self-hosted were found to be vulnerable.
This issue has already been mitigated for Looker-hosted instances. No user action is required for these.
Self-hosted instances must be upgraded as soon as possible. This vulnerability has been patched in all supported versions of Self-hosted.
The versions below have all been updated to protect against this vulnerability. You can download these versions at the Looker download page https://download.looker.com/ :
* 24.12.106
* 24.18.198+
* 25.0.75
* 25.6.63+
* 25.8.45+
* 25.10.33+
* 25.12.1+
* 25.14+ |
| A remote command execution (RCE) vulnerability was discovered in all H3C ERG3/ERG5 series routers and XiaoBei series routers, cloud gateways, and wireless access points (versions R0162P07, UAP700-WPT330-E2265, UAP672-WPT330-R2262, UAP662E-WPT330-R2262P03, WAP611-WPT330-R1348-OASIS, WAP662-WPT330-R2262, WAP662H-WPT330-R2262, USG300V2-WPT330-R2129, MSG300-WPT330-R1350, and MSG326-WPT330-R2129). Attackers are able to exploit this vulnerability via injecting crafted commands into the sessionid parameter. |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Narkom Communication and Software Technologies Trade Ltd. Co. Pyxis Signage allows Stored XSS.This issue affects Pyxis Signage: through 31012025. |
| The WP Import – Ultimate CSV XML Importer for WordPress plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 7.33.1. This is due to deserialization of untrusted data supplied via CSV file imports in the import_single_post_as_csv function within SingleImportExport.php. This makes it possible for authenticated attackers, with administrator-level access or higher, to inject a PHP object. If a POP chain is present via an additional plugin or theme installed on the target system, it could allow the attacker to delete arbitrary files, retrieve sensitive data, or execute code. |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in opentext uCMDB allows Stored XSS. The vulnerability could allow an attacker has high level access to UCMDB to create or update data with malicious scripts
This issue affects uCMDB: 24.4. |
| A Cross-Site Request Forgery (CSRF) vulnerability was identified in HCL Glovius Cloud. An attacker can force a user's web browser to execute an unwanted, malicious action on a trusted site where the user is authenticated, specifically on one endpoint. |
| Improper Control of Generation of Code ('Code Injection') vulnerability in Progress DataDirect Connect for JDBC drivers, Progress DataDirect Open Access JDBC driver and Hybrid Data Pipeline allows Remote Code Inclusion.
The SpyAttribute connection option implemented by the DataDirect Connect for JDBC drivers, DataDirect Hybrid Data Pipeline JDBC driver and the DataDirect OpenAccess JDBC driver log=(file) construct allows the user to specify an arbitrary file for the JDBC driver to write its log information to. If an application allows an end user to specify a value for the SpyAttributes connection option then an attacker could cause java script to be written to a log file. If the log file was in the correct location with the correct extension, an application server could see that log file as a resource to be served. The attacker could fetch the resource from the server causing the java script to be executed.
This issue affects:
DataDirect Connect for JDBC for Amazon Redshift: through 6.0.0.001392, fixed in 6.0.0.001541
DataDirect Connect for JDBC for Apache Cassandra: through 6.0.0.000805, fixed in 6.0.0.000833
DataDirect Connect for JDBC for Hive: through 6.0.1.001499, fixed in 6.0.1.001628
DataDirect Connect for JDBC for Apache Impala: through 6.0.0.001155, fixed in 6.0.0.001279
DataDirect Connect for JDBC for Apache SparkSQL: through 6.0.1.001222, fixed in 6.0.1.001344
DataDirect Connect for JDBC Autonomous REST Connector: through 6.0.1.006961, fixed in 6.0.1.007063
DataDirect Connect for JDBC for DB2: through 6.0.0.000717, fixed in 6.0.0.000964
DataDirect Connect for JDBC for Google Analytics 4: through 6.0.0.000454, fixed in 6.0.0.000525
DataDirect Connect for JDBC for Google BigQuery: through 6.0.0.002279, fixed in 6.0.0.002410
DataDirect Connect for JDBC for Greenplum: through 6.0.0.001712, fixed in 6.0.0.001727
DataDirect Connect for JDBC for Informix: through 6.0.0.000690, fixed in 6.0.0.0851
DataDirect Connect for JDBC for Microsoft Dynamics 365: through 6.0.0.003161, fixed in 6.0.0.3198
DataDirect Connect for JDBC for Microsoft SQLServer: through 6.0.0.001936, fixed in 6.0.0.001957
DataDirect Connect for JDBC for Microsoft Sharepoint: through 6.0.0.001559, fixed in 6.0.0.001587
DataDirect Connect for JDBC for MongoDB: through 6.1.0.001654, fixed in 6.1.0.001669
DataDirect Connect for JDBC for MySQL: through 5.1.4.000330, fixed in 5.1.4.000364
DataDirect Connect for JDBC for Oracle Database: through 6.0.0.001747, fixed in 6.0.0.001776
DataDirect Connect for JDBC for Oracle Eloqua: through 6.0.0.001438, fixed in 6.0.0.001458
DataDirect Connect for JDBC for Oracle Sales Cloud: through 6.0.0.001225, fixed in 6.0.0.001316
DataDirect Connect for JDBC for Oracle Service Cloud: through 5.1.4.000298, fixed in 5.1.4.000309
DataDirect Connect for JDBC for PostgreSQL: through 6.0.0.001843, fixed in 6.0.0.001856
DataDirect Connect for JDBC for Progress OpenEdge: through 5.1.4.000187, fixed in 5.1.4.000189
DataDirect Connect for JDBC for Salesforce: through 6.0.0.003020, fixed in 6.0.0.003125
DataDirect Connect for JDBC for SAP HANA: through 6.0.0.000879, product retired
DataDirect Connect for JDBC for SAP S/4 HANA: through 6.0.1.001818, fixed in 6.0.1.001858
DataDirect Connect for JDBC for Sybase ASE: through 5.1.4.000161, fixed in 5.1.4.000162
DataDirect Connect for JDBC for Snowflake: through 6.0.1.001821, fixed in 6.0.1.001856
DataDirect Hybrid Data Pipeline Server: through 4.6.2.3309, fixed in 4.6.2.3430
DataDirect Hybrid Data Pipeline JDBC Driver: through 4.6.2.0607, fixed in 4.6.2.1023
DataDirect Hybrid Data Pipeline On Premises Connector: through 4.6.2.1223, fixed in 4.6.2.1339
DataDirect Hybrid Data Pipeline Docker: through 4.6.2.3316, fixed in 4.6.2.3430
DataDirect OpenAccess JDBC Driver: through 8.1.0.0177, fixed in 8.1.0.0183
DataDirect OpenAccess JDBC Driver: through 9.0.0.0019, fixed in 9.0.0.0022 |
| Lookyloo is a web interface that allows users to capture a website page and then display a tree of domains that call each other. Prior to version 1.35.1, there is potential cross-site scripting on index and tree page. This issue has been patched in version 1.35.1. |
| BASIS BBj versions prior to 25.00 contain a Jetty-served web endpoint that fails to properly validate or canonicalize input path segments. This allows unauthenticated directory traversal sequences to cause the server to read arbitrary system files accessible to the account running the service. Retrieved configuration artifacts may contain account credentials used for BBj Enterprise Manager; possession of these credentials enables administrative access and use of legitimate management functionality that can result in execution of system commands under the service account. Depending on the operating system and the privileges of the BBj service account, this issue may also allow access to other sensitive files on the host, including operating system or application data, potentially exposing additional confidential information. |
