| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Free sp in error path to fix system crash
System crash seen during load/unload test in a loop,
[61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X.
[61110.467494] =============================================================================
[61110.467498] BUG qla2xxx_srbs (Tainted: G OE -------- --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown()
[61110.467501] -----------------------------------------------------------------------------
[61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff)
[61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1
[61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023
[61110.467515] Call Trace:
[61110.467516] <TASK>
[61110.467519] dump_stack_lvl+0x34/0x48
[61110.467526] slab_err.cold+0x53/0x67
[61110.467534] __kmem_cache_shutdown+0x16e/0x320
[61110.467540] kmem_cache_destroy+0x51/0x160
[61110.467544] qla2x00_module_exit+0x93/0x99 [qla2xxx]
[61110.467607] ? __do_sys_delete_module.constprop.0+0x178/0x280
[61110.467613] ? syscall_trace_enter.constprop.0+0x145/0x1d0
[61110.467616] ? do_syscall_64+0x5c/0x90
[61110.467619] ? exc_page_fault+0x62/0x150
[61110.467622] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd
[61110.467626] </TASK>
[61110.467627] Disabling lock debugging due to kernel taint
[61110.467635] Object 0x0000000026f7e6e6 @offset=16000
[61110.467639] ------------[ cut here ]------------
[61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx]
[61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160
[61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G B OE -------- --- 5.14.0-284.11.1.el9_2.x86_64 #1
[61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023
[61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160
[61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89
[61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282
[61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027
[61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0
[61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7
[61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000
[61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[61110.467733] FS: 00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000
[61110.467734] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0
[61110.467736] PKRU: 55555554
[61110.467737] Call Trace:
[61110.467738] <TASK>
[61110.467739] qla2x00_module_exit+0x93/0x99 [qla2xxx]
[61110.467755] ? __do_sys_delete_module.constprop.0+0x178/0x280
Free sp in the error path to fix the crash. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: bcm-sba-raid: fix device leak on probe
Make sure to drop the reference taken when looking up the mailbox device
during probe on probe failures and on driver unbind. |
| In the Linux kernel, the following vulnerability has been resolved:
via_wdt: fix critical boot hang due to unnamed resource allocation
The VIA watchdog driver uses allocate_resource() to reserve a MMIO
region for the watchdog control register. However, the allocated
resource was not given a name, which causes the kernel resource tree
to contain an entry marked as "<BAD>" under /proc/iomem on x86
platforms.
During boot, this unnamed resource can lead to a critical hang because
subsequent resource lookups and conflict checks fail to handle the
invalid entry properly. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix reference count leak when using error routes with nexthop objects
When a nexthop object is deleted, it is marked as dead and then
fib_table_flush() is called to flush all the routes that are using the
dead nexthop.
The current logic in fib_table_flush() is to only flush error routes
(e.g., blackhole) when it is called as part of network namespace
dismantle (i.e., with flush_all=true). Therefore, error routes are not
flushed when their nexthop object is deleted:
# ip link add name dummy1 up type dummy
# ip nexthop add id 1 dev dummy1
# ip route add 198.51.100.1/32 nhid 1
# ip route add blackhole 198.51.100.2/32 nhid 1
# ip nexthop del id 1
# ip route show
blackhole 198.51.100.2 nhid 1 dev dummy1
As such, they keep holding a reference on the nexthop object which in
turn holds a reference on the nexthop device, resulting in a reference
count leak:
# ip link del dev dummy1
[ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2
Fix by flushing error routes when their nexthop is marked as dead.
IPv6 does not suffer from this problem. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/cm: Fix leaking the multicast GID table reference
If the CM ID is destroyed while the CM event for multicast creating is
still queued the cancel_work_sync() will prevent the work from running
which also prevents destroying the ah_attr. This leaks a refcount and
triggers a WARN:
GID entry ref leak for dev syz1 index 2 ref=573
WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]
WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886
Destroy the ah_attr after canceling the work, it is safe to call this
twice. |
| In the Linux kernel, the following vulnerability has been resolved:
eth: fbnic: Fix payload page pool error cleanup
The payload page pool pointer contains an error pointer when its
allocation fails. The cleanup path passes that error pointer to
page_pool_destroy() instead of destroying the header page pool. This
can dereference the error pointer and leave the header page pool
allocated.
Destroy the header page pool instead. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: fix object leaks in virtio_gpu_resource_create_blob_ioctl()
virtio_gpu_resource_create_blob_ioctl() calls drm_gem_object_release() on
both the virtio_gpu_resource_assign_uuid() and drm_gem_handle_create()
error paths instead of dropping the reference it owns, so
obj->funcs->free() never runs and the virtio_gpu_object, the resource id
and the host-side resource are leaked.
Use drm_gem_object_put() instead. |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: Prevent rt6_insert_exception() for dying fib6_info.
Before the cited commit, fib6_nh_flush_exceptions() always set
from->exception_bucket_flushed = 1 under rt6_exception_lock to
prevent rt6_insert_exception() from inserting a new exception
for a dying fib6_info.
The flag was replaced with the FIB6_EXCEPTION_BUCKET_FLUSHED
bit stored in nh->rt6i_exception_bucket.
The problem is that now the bit is only set when the bucket
is not NULL and fib6_nh_flush_exceptions() is called from
fib6_nh_release() after fib6_ref has already reached zero.
If rt6_insert_exception() is called while the target fib6_info
is being removed via fib6_purge_rt(), a new exception could be
created successfully because rt6_flush_exceptions() no longer
sets the bit.
This creates a reference cycle between the fib6_info and the
exception route, leaking the fib6_info, its nexthop device,
and all per-CPU routes in fib6_nh->rt6i_pcpu, which stalls netdev
unregistration.
[ 34.680602] unregister_netdevice: waiting for gre6 to become free. Usage count = 68
[ 44.920675] unregister_netdevice: waiting for gre6 to become free. Usage count = 68
[ 55.176582] unregister_netdevice: waiting for gre6 to become free. Usage count = 68
Let's call fib6_drop_pcpu_from() before rt6_flush_exceptions(),
to set fib6_destroying before rt6_exception_lock, and check
f6i->fib6_destroying in rt6_insert_exception().
Note that FIB6_EXCEPTION_BUCKET_FLUSHED logic is dead and
we can clean it up in net-next. |
| In the Linux kernel, the following vulnerability has been resolved:
net: macb: fix dma_alloc_coherent() leak on macb_alloc() error paths
Fix 3 leaks in macb_alloc() error paths:
- Tx buffer allocated but crossing a 4G boundary: Tx leaked.
- Rx buffer allocation fails: Tx leaked.
- Rx buffer allocated but crossing a 4G boundary: Tx & Rx leaked.
This is because our error handling calls macb_free(bp) which in turn
frees the buffers stored in bp->queues[0], but nothing has been stored
in there. Fix by storing allocated buffers into bp->queues[0] ASAP. |
| In the Linux kernel, the following vulnerability has been resolved:
s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config
Three related problems exist in the handling of KVM interrupt and page
resources when a queue is removed from the host's AP configuration
while assigned to a mediated device (mdev).
Problem 1:
~~~~~~~~~
AP_RESPONSE_Q_NOT_AVAIL not handled in vfio_ap_mdev_reset_queue()
When the AP bus removes a queue device whose adapter or domain has
been removed from the host's AP configuration,
vfio_ap_mdev_remove_queue() is called. If the queue is still in the
host's AP configuration at that point, it calls
vfio_ap_mdev_reset_queue(), which issues a PQAP(ZAPQ). Since the
adapter is already gone from the host configuration, ap_zapq() returns
AP_RESPONSE_Q_NOT_AVAIL (0x01). This response code is not handled in
vfio_ap_mdev_reset_queue()'s switch statement and falls through to
the default case, which issues a WARN but does not call
vfio_ap_free_aqic_resources(). As a result, if IRQ handling was
enabled for the queue by the guest, the KVM GISC registration and
the pinned guest page holding the notification indicator byte (NIB)
are both leaked.
This is fixed by adding AP_RESPONSE_Q_NOT_AVAIL to the same case as
AP_RESPONSE_DECONFIGURED and AP_RESPONSE_CHECKSTOPPED in
vfio_ap_mdev_reset_queue(). Like those response codes, Q_NOT_AVAIL
indicates the queue is not operational and no further reset attempts
are possible; the correct action is to free the IRQ resources
immediately.
Problem 2:
~~~~~~~~~
AP_RESPONSE_Q_NOT_AVAIL not handled in apq_status_check()
In vfio_ap_mdev_reset_queue(), there are four cases that indicate a queue
reset has not yet completed, in which case apq_reset_check() is queued to
a work queue to verify completion of the reset operation. This function
uses the PQAP(TAPQ) function to get the queue's status and calls
apq_status_check() to verify whether the reset has completed, failed or
needs to be executed again. As described in Problem #1 above,
apq_reset_check() does not specifically check for AP_RESPONSE_Q_NOT_AVAIL,
thereby potentially leaking KVM GISC registration and the pinned guest page
holding the NIB.
This is fixed by adding a case statement for AP_RESPONSE_Q_NOT_AVAIL to
apq_status_check() and returning -ENODEV for that case. The caller,
apq_reset_check() will then check for this return code and call
vfio_ap_free_aqic_resources() to prevent the leak.
Problem 3:
~~~~~~~~~
vfio_ap_free_aqic_resources() leaks saved_isc when kvm is NULL
vfio_ap_free_aqic_resources() guards the call to
kvm_s390_gisc_unregister() with:
if (q->saved_isc != VFIO_AP_ISC_INVALID &&
!WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm)))
If matrix_mdev->kvm is NULL -- which can happen when
vfio_ap_mdev_unset_kvm() has already run and cleared kvm before a
subsequent cleanup path reaches this function -- the WARN_ON fires
and the entire block is skipped. This leaves q->saved_isc set to a
non-invalid value, creating a potential double-free on any subsequent
call to this function.
When kvm is NULL the KVM guest is already torn down, so
kvm_s390_gisc_unregister() need not and cannot be called; however,
q->saved_isc must always be cleared. Fix this by separating the
kvm_s390_gisc_unregister() call from the q->saved_isc reset. The
WARN_ON now guards only the genuinely impossible case of matrix_mdev
being NULL. A NULL kvm is handled gracefully by skipping only the
unregister call, and q->saved_isc = VFIO_AP_ISC_INVALID is set
unconditionally whenever saved_isc was not already invalid.
Additionally, add an else clause to the host-config check in
vfio_ap_mdev_remove_queue() to call vfio_ap_free_aqic_resources()
directly when the queue is not in the host's AP configuration. This
serves as a backstop: when the AP bus fires the driver .remove
callback after an adapter is removed from the host config, the queue
is by definition no longer addressable, so vfio_ap_mdev_reset_queue
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
module: fix lost error code from codetag_load_module()
If codetag_load_module() fails, err is not set to reflect the failure
and load_module() returns 0 after the module has been torn down.
Also, if the module is a livepatch, mod->klp_info allocated by
copy_module_elf() leaks on this error path. Free it via a new
livepatch_cleanup label. |
| ImageMagick before 6.9.13-57 and 7.x before 7.1.2-32 contains a memory leak in the GIF encoder because allocated memory is not released when color quantization fails during encoding. Attackers can supply images whose GIF conversion causes quantization to fail, leaking memory with each attempt and degrading availability. |
| Missing release of memory after effective lifetime in Windows DNS allows an unauthorized attacker to deny service over a network. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the packet forwarding engine (PFE) of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause a complete Denial-of-Service (DoS).
On SRX4000 Series, and SRX5000 Series with SPC3, and MX Series with SPC3, when one or more specific application services like ALGs, IDP/DPI, APPID, SECINTEL, AAMW or AppQoE are configured, a high connections per second churn will cause PFE memory to leak. If the memory is exhausted traffic processing will be impacted.
Use the CLI command show security monitoring to monitor the memory utilization of the PFEs on the FPCs.
This issue affects Junos OS on SRX Series and MX Series:
* 23.4 versions from 23.4R2-S3 before 23.4R2-S7;
* 24.2 versions from 24.2R2 before 24.2R2-S3;
* 24.4 versions before 24.4R2-S3;
* 25.2 versions before 25.2R1-S2, 25.2R2. |
| An Improper Release of Memory Before Removing Last Reference vulnerability in the l2cpd process of Juniper Networks Junos OS and Junos OS Evolved platforms allows an adjacent unauthenticated attacker to cause l2cpd memory exhaustion and Layer 2 control-plane disruption via LLDP traffic when fast receive processing is enabled. |
| An Improper Release of Memory Before Removing Last Reference vulnerability in the l2ald process of Juniper Networks Junos OS and Junos OS Evolved on QFX5K-family platforms allows a configured EVPN peer to cause a denial of service through memory exhaustion via EVPN-VXLAN active-active multihoming route processing. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the l2ald process of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker to cause a denial of service via crafted packets when the static MAC-IP feature is in use. |
| Description
NGINX JavaScript (njs) has a vulnerability where the built-in njs engine leaks a libxml2 parser context when xml.parse() fails. The failure path did not register cleanup and the context was not released for the lifetime of the process. An unauthenticated attacker may send requests with malformed XML and can cause unbounded memory growth in long-lived NGINX worker processes.
Impact
This vulnerability may allow remote attackers to send requests that trigger repeated parsing of malformed XML and may lead to NGINX worker termination or denial of service. There is no control plane exposure; this is a data plane issue only.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. |
| In the Linux kernel, the following vulnerability has been resolved:
IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier
mlx5_ib_alloc_transport_domain() allocates a transport domain and then
may fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.
Fix this by deallocating the TD when mlx5_ib_enable_lb() returns an
error. Also return 0 explicitly in the no-loopback-capability success
branch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init(). |
| The Link Layer Control Procedure (LLCP) implementation of the Zephyr software Bluetooth LE Controller retains the receive node that carried an accepted LL_PHY_UPDATE_IND so that it can later be reused for the host notification when the update instant is reached (llcp_rx_node_retain() in subsys/bluetooth/controller/ll_sw/ull_llcp.c, and the node is deliberately not recycled while marked NODE_RX_TYPE_RETAIN). The invalid-PDU arms of llcp_lp_pu_rx() and llcp_rp_pu_rx() in subsys/bluetooth/controller/ll_sw/ull_llcp_phy.c completed the procedure via llcp_lr_complete() / llcp_rr_complete() without first releasing that retained node, so the procedure context — the only remaining reference to the node — was freed while the node was still held out of the receive pool.
A peer device on an established LE connection can drive this deterministically and without pairing or encryption. Against a peripheral it sends LL_PHY_REQ, receives LL_PHY_RSP, sends a valid LL_PHY_UPDATE_IND with an instant a few connection events in the future (so the node becomes retained), and then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ; ull_cp_rx() routes it to the active remote PHY Update procedure, which takes the invalid-PDU path. The mirror case applies to a locally initiated PHY Update followed by an LL_REJECT_IND.
In the default configuration (CONFIG_BT_ASSERT and CONFIG_BT_CTLR_ASSERT_DEBUG both default y) the violated invariant in llcp_lr_check_done() / llcp_rr_check_done() triggers a controller assertion, ending in k_oops() (or k_panic()) — a single crafted PDU sequence from radio range faults the device. With those assertions compiled out, each attempt silently leaks one receive PDU node and its memq link; because the controller receive pool is small (PDU_RX_CNT, driven by CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1) and each attempt costs the attacker only a reconnect, a few repetitions exhaust the pool and leave Bluetooth inoperable until reboot. On releases v3.4.0 through v3.7.x the assertion is never reached, whatever the configuration, so every attempt leaks silently.
The impact is limited to availability: the orphaned node leaves no dangling pointer that is later dereferenced and is never delivered to the host, so there is no memory corruption or information disclosure. The same pull request applies the identical release to the Connection Update and CIS-create procedures, whose invalid-PDU arms had the same omission. |
