| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A Missing Release of Memory after Effective Lifetime vulnerability in the packet forwarding engine (PFE) of Juniper Networks Junos OS on MX Series allows an unauthenticated adjacent attacker to cause a Denial-of-Service (DoS).
In a subscriber management scenario, login/logout activity triggers a memory leak, and the leaked memory gradually increments and eventually results in a crash.
user@host> show chassis fpc
Temp CPU Utilization (%) CPU Utilization (%) Memory Utilization (%)
Slot State (C) Total Interrupt 1min 5min 15min DRAM (MB) Heap Buffer
2 Online 36 10 0 9 8 9 32768 26 0
This issue affects Junos OS on MX Series:
* All versions before 21.2R3-S9
* from 21.4 before 21.4R3-S10
* from 22.2 before 22.2R3-S6
* from 22.4 before 22.4R3-S5
* from 23.2 before 23.2R2-S3
* from 23.4 before 23.4R2-S3
* from 24.2 before 24.2R2. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of the Juniper Networks Junos OS on the MX Series platforms with Trio-based FPCs allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS).
In case of channelized Modular Interface Cards (MICs), every physical interface flap operation will leak heap memory. Over a period of time, continuous physical interface flap operations causes local FPC to eventually run out of memory and crash.
Below CLI command can be used to check the memory usage over a period of time:
user@host> show chassis fpc
Temp CPU Utilization (%) CPU Utilization (%) Memory
Utilization (%)
Slot State (C) Total Interrupt 1min 5min
15min DRAM (MB) Heap Buffer
0
Online 43 41
2 2048 49 14
1
Online 43 41
2
2048 49 14
2
Online 43 41
2
2048 49 14
This issue affects Junos OS on MX Series:
* All versions before 21.2R3-S7,
* from 21.4 before 21.4R3-S6,
* from 22.1 before 22.1R3-S5,
* from 22.2 before 22.2R3-S3,
* from 22.3 before 22.3R3-S2,
* from 22.4 before 22.4R3,
* from 23.2 before 23.2R2,
* from 23.4 before 23.4R2. |
| Multiple denial-of-service vulnerabilities exist in the affected product. These issues can be triggered through various crafted inputs, including malformed Class 3 messages, memory leak conditions, and other resource exhaustion scenarios. Exploitation may cause the device to become unresponsive and, in some cases, result in a major nonrecoverable fault. Recovery may require a restart. |
| In the Linux kernel, the following vulnerability has been resolved:
thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()
The memory allocated in tb_queue_dp_bandwidth_request() needs to be
released once the request is handled to avoid leaking it. |
| In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix leak in devfreq_dev_release()
srcu_init_notifier_head() allocates resources that need to be released
with a srcu_cleanup_notifier_head() call.
Reported by kmemleak. |
| In the Linux kernel, the following vulnerability has been resolved:
gpu: host1x: Fix memory leak of device names
The device names allocated by dev_set_name() need be freed
before module unloading, but they can not be freed because
the kobject's refcount which was set in device_initialize()
has not be decreased to 0.
As comment of device_add() says, if it fails, use only
put_device() drop the refcount, then the name will be
freed in kobejct_cleanup().
device_del() and put_device() can be replaced with
device_unregister(), so call it to unregister the added
successfully devices, and just call put_device() to the
not added device.
Add a release() function to device to avoid null release()
function WARNING in device_release(), it's empty, because
the context devices are freed together in
host1x_memory_context_list_free(). |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Fix a memory leak
Add a forgotten kfree(). |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: Fix memory leak in rtw88_usb
Kmemleak shows the following leak arising from routine in the usb
probe routine:
unreferenced object 0xffff895cb29bba00 (size 512):
comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s)
hex dump (first 32 bytes):
77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0...
02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U......
backtrace:
[<ffffffff9265fa36>] kmalloc_trace+0x26/0x90
[<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb]
[<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore]
[<ffffffff92b4f2fe>] really_probe+0x18e/0x3d0
[<ffffffff92b4f5b8>] __driver_probe_device+0x78/0x160
[<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90
[<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0
[<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0
[<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210
[<ffffffff92b50935>] driver_register+0x55/0xf0
[<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore]
[<ffffffff92401153>] do_one_initcall+0x43/0x210
[<ffffffff9254f42a>] do_init_module+0x4a/0x200
[<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120
[<ffffffff92ee6626>] do_syscall_64+0x56/0x80
[<ffffffff9300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
The leak was verified to be real by unloading the driver, which resulted
in a dangling pointer to the allocation.
The allocated memory is freed in rtw_usb_intf_deinit(). |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix potential memory leaks
When the driver hits -ENOMEM at allocating a URB or a buffer, it
aborts and goes to the error path that releases the all previously
allocated resources. However, when -ENOMEM hits at the middle of the
sync EP URB allocation loop, the partially allocated URBs might be
left without released, because ep->nurbs is still zero at that point.
Fix it by setting ep->nurbs at first, so that the error handler loops
over the full URB list. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd: fix potential memory leak
This patch fix potential memory leak (clk_src) when function run
into last return NULL.
s/free/kfree/ - Alex |
| A Missing Release of Memory after Effective Lifetime vulnerability in the routing protocol daemon (rpd) Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated attacker controlling an adjacent IS-IS neighbor to send a specific update packet causing a memory leak. Continued receipt and processing of these packets will exhaust all available memory, crashing rpd and creating a Denial of Service (DoS) condition.
Memory usage can be monitored through the use of the 'show task memory detail' command. For example:
user@junos> show task memory detail | match ted-infra
TED-INFRA-COOKIE 25 1072 28 1184 229
user@junos>
show task memory detail | match ted-infra
TED-INFRA-COOKIE 31 1360 34 1472 307
This issue affects:
Junos OS:
* from 23.2 before 23.2R2,
* from 23.4 before 23.4R1-S2, 23.4R2,
* from 24.1 before 24.1R2;
Junos OS Evolved:
* from 23.2 before 23.2R2-EVO,
* from 23.4 before 23.4R1-S2-EVO, 23.4R2-EVO,
* from 24.1 before 24.1R2-EVO.
This issue does not affect Junos OS versions before 23.2R1 or Junos OS Evolved versions before 23.2R1-EVO. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Anti-Virus processing of Juniper Networks Junos OS on SRX Series
allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS).
On all SRX platforms with Anti-Virus enabled, if a server sends specific content in the HTTP body of a response to a client request, these packets are queued by Anti-Virus processing in Juniper Buffers (jbufs) which are never released. When these jbufs are exhausted, the device stops forwarding all transit traffic.
A jbuf memory leak can be noticed from the following logs:
(<node>.)<fpc> Warning: jbuf pool id <#> utilization level (<current level>%) is above <threshold>%!
To recover from this issue, the affected device needs to be manually rebooted to free the leaked jbufs.
This issue affects Junos OS on SRX Series:
* all versions before 21.2R3-S9,
* 21.4 versions before 21.4R3-S10,
* 22.2 versions before 22.2R3-S6,
* 22.4 versions before 22.4R3-S6,
* 23.2 versions before 23.2R2-S3,
* 23.4 versions before 23.4R2-S3,
* 24.2 versions before 24.2R2. |
| In the Linux kernel, the following vulnerability has been resolved:
macintosh: fix possible memory leak in macio_add_one_device()
Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically. It
needs to be freed when of_device_register() fails. Call put_device() to
give up the reference that's taken in device_initialize(), so that it
can be freed in kobject_cleanup() when the refcount hits 0.
macio device is freed in macio_release_dev(), so the kfree() can be
removed. |
| In the Linux kernel, the following vulnerability has been resolved:
ntb_netdev: Use dev_kfree_skb_any() in interrupt context
TX/RX callback handlers (ntb_netdev_tx_handler(),
ntb_netdev_rx_handler()) can be called in interrupt
context via the DMA framework when the respective
DMA operations have completed. As such, any calls
by these routines to free skb's, should use the
interrupt context safe dev_kfree_skb_any() function.
Previously, these callback handlers would call the
interrupt unsafe version of dev_kfree_skb(). This has
not presented an issue on Intel IOAT DMA engines as
that driver utilizes tasklets rather than a hard
interrupt handler, like the AMD PTDMA DMA driver.
On AMD systems, a kernel WARNING message is
encountered, which is being issued from
skb_release_head_state() due to in_hardirq()
being true.
Besides the user visible WARNING from the kernel,
the other symptom of this bug was that TCP/IP performance
across the ntb_netdev interface was very poor, i.e.
approximately an order of magnitude below what was
expected. With the repair to use dev_kfree_skb_any(),
kernel WARNINGs from skb_release_head_state() ceased
and TCP/IP performance, as measured by iperf, was on
par with expected results, approximately 20 Gb/s on
AMD Milan based server. Note that this performance
is comparable with Intel based servers. |
| In the Linux kernel, the following vulnerability has been resolved:
rtc: class: Fix potential memleak in devm_rtc_allocate_device()
devm_rtc_allocate_device() will alloc a rtc_device first, and then run
dev_set_name(). If dev_set_name() failed, the rtc_device will memleak.
Move devm_add_action_or_reset() in front of dev_set_name() to prevent
memleak.
unreferenced object 0xffff888110a53000 (size 2048):
comm "python3", pid 470, jiffies 4296078308 (age 58.882s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0......
08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0..............
backtrace:
[<000000004aac0364>] kmalloc_trace+0x21/0x110
[<000000000ff02202>] devm_rtc_allocate_device+0xd4/0x400
[<000000001bdf5639>] devm_rtc_device_register+0x1a/0x80
[<00000000351bf81c>] rx4581_probe+0xdd/0x110 [rtc_rx4581]
[<00000000f0eba0ae>] spi_probe+0xde/0x130
[<00000000bff89ee8>] really_probe+0x175/0x3f0
[<00000000128e8d84>] __driver_probe_device+0xe6/0x170
[<00000000ee5bf913>] device_driver_attach+0x32/0x80
[<00000000f3f28f92>] bind_store+0x10b/0x1a0
[<000000009ff812d8>] drv_attr_store+0x49/0x70
[<000000008139c323>] sysfs_kf_write+0x8d/0xb0
[<00000000b6146e01>] kernfs_fop_write_iter+0x214/0x2d0
[<00000000ecbe3895>] vfs_write+0x61a/0x7d0
[<00000000aa2196ea>] ksys_write+0xc8/0x190
[<0000000046a600f5>] do_syscall_64+0x37/0x90
[<00000000541a336f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
| In the Linux kernel, the following vulnerability has been resolved:
blk-mq: fix possible memleak when register 'hctx' failed
There's issue as follows when do fault injection test:
unreferenced object 0xffff888132a9f400 (size 512):
comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2....
08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............
backtrace:
[<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0
[<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0
[<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230
[<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910
[<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0
[<00000000a2a34657>] 0xffffffffa2ad310f
[<00000000b173f718>] 0xffffffffa2af824a
[<0000000095a1dabb>] do_one_initcall+0x87/0x2a0
[<00000000f32fdf93>] do_init_module+0xdf/0x320
[<00000000cbe8541e>] load_module+0x3006/0x3390
[<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0
[<00000000a1a29ae8>] do_syscall_64+0x35/0x80
[<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Fault injection context as follows:
kobject_add
blk_mq_register_hctx
blk_mq_sysfs_register
blk_register_queue
device_add_disk
null_add_dev.part.0 [null_blk]
As 'blk_mq_register_hctx' may already add some objects when failed halfway,
but there isn't do fallback, caller don't know which objects add failed.
To solve above issue just do fallback when add objects failed halfway in
'blk_mq_register_hctx'. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: tegra: tegra124-emc: Fix potential memory leak
The tegra and tegra needs to be freed in the error handling path, otherwise
it will be leaked. |
| A Missing Release of Memory after Effective Lifetime vulnerability in the Periodic Packet Management Daemon (ppmd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker to cause a
Denial-of-Service (DoS).
When a BFD session configured with authentication flaps, ppmd memory can leak. Whether the leak happens depends on a race condition which is outside the attackers control. This issue only affects BFD operating in distributed aka delegated (which is the default behavior) or inline mode.
Whether the leak occurs can be monitored with the following CLI command:
> show ppm request-queue
FPC Pending-request
fpc0 2
request-total-pending: 2
where a continuously increasing number of pending requests is indicative of the leak.
This issue affects:
Junos OS:
* All versions before 21.2R3-S8,
* 21.4 versions before 21.4R3-S7,
* 22.1 versions before 22.1R3-S4,
* 22.2 versions before 22.2R3-S4,
* 22.3 versions before 22.3R3,
* 22.4 versions before 22.4R2-S2, 22.4R3.
Junos OS Evolved:
* All versions before 21.2R3-S8-EVO,
* 21.4-EVO versions before 21.4R3-S7-EVO,
* 22.2-EVO versions before 22.2R3-S4-EVO,
* 22.3-EVO versions before 22.3R3-EVO,
* 22.4-EVO versions before 22.4R3-EVO. |
| In the Linux kernel, the following vulnerability has been resolved:
phonet: fix rtm_phonet_notify() skb allocation
fill_route() stores three components in the skb:
- struct rtmsg
- RTA_DST (u8)
- RTA_OIF (u32)
Therefore, rtm_phonet_notify() should use
NLMSG_ALIGN(sizeof(struct rtmsg)) +
nla_total_size(1) +
nla_total_size(4) |
| In the Linux kernel, the following vulnerability has been resolved:
netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed
If some items in nsim_dev_resources_register() fail, memory leak will
occur. The following is the memory leak information.
unreferenced object 0xffff888074c02600 (size 128):
comm "echo", pid 8159, jiffies 4294945184 (age 493.530s)
hex dump (first 32 bytes):
40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G..............
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
backtrace:
[<0000000011a31c98>] kmalloc_trace+0x22/0x60
[<0000000027384c69>] devl_resource_register+0x144/0x4e0
[<00000000a16db248>] nsim_drv_probe+0x37a/0x1260
[<000000007d1f448c>] really_probe+0x20b/0xb10
[<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0
[<00000000077e0351>] driver_probe_device+0x49/0x140
[<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0
[<000000008538f359>] bus_for_each_drv+0x151/0x1d0
[<0000000038e09747>] __device_attach+0x1c9/0x4e0
[<00000000dd86e533>] bus_probe_device+0x1d5/0x280
[<00000000839bea35>] device_add+0xae0/0x1cb0
[<000000009c2abf46>] new_device_store+0x3b6/0x5f0
[<00000000fb823d7f>] bus_attr_store+0x72/0xa0
[<000000007acc4295>] sysfs_kf_write+0x106/0x160
[<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0
[<0000000075eb41bf>] vfs_write+0x8f0/0xc80 |
