| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
tls: fix handling of zero-length records on the rx_list
Each recvmsg() call must process either
- only contiguous DATA records (any number of them)
- one non-DATA record
If the next record has different type than what has already been
processed we break out of the main processing loop. If the record
has already been decrypted (which may be the case for TLS 1.3 where
we don't know type until decryption) we queue the pending record
to the rx_list. Next recvmsg() will pick it up from there.
Queuing the skb to rx_list after zero-copy decrypt is not possible,
since in that case we decrypted directly to the user space buffer,
and we don't have an skb to queue (darg.skb points to the ciphertext
skb for access to metadata like length).
Only data records are allowed zero-copy, and we break the processing
loop after each non-data record. So we should never zero-copy and
then find out that the record type has changed. The corner case
we missed is when the initial record comes from rx_list, and it's
zero length. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: smartpqi: Fix smp_processor_id() call trace for preemptible kernels
Correct kernel call trace when calling smp_processor_id() when called in
preemptible kernels by using raw_smp_processor_id().
smp_processor_id() checks to see if preemption is disabled and if not,
issue an error message followed by a call to dump_stack().
Brief example of call trace:
kernel: check_preemption_disabled: 436 callbacks suppressed
kernel: BUG: using smp_processor_id() in preemptible [00000000]
code: kworker/u1025:0/2354
kernel: caller is pqi_scsi_queue_command+0x183/0x310 [smartpqi]
kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0
kernel: ...
kernel: Workqueue: writeback wb_workfn (flush-253:0)
kernel: Call Trace:
kernel: <TASK>
kernel: dump_stack_lvl+0x34/0x48
kernel: check_preemption_disabled+0xdd/0xe0
kernel: pqi_scsi_queue_command+0x183/0x310 [smartpqi]
kernel: ... |
| In the Linux kernel, the following vulnerability has been resolved:
perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create()
The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses
smp_processor_id(), which assumes disabled preemption. This leads to kernel
warnings during module loading because meson_ddr_pmu_create() can be called
in a preemptible context.
Following kernel warning and stack trace:
[ 31.745138] [ T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289
[ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38
[ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0
[ 31.745181] [ T2289] Tainted: [W]=WARN
[ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT)
[ 31.745188] [ T2289] Call trace:
[ 31.745191] [ T2289] show_stack+0x28/0x40 (C)
[ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198
[ 31.745205] [ T2289] dump_stack+0x20/0x50
[ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0
[ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38
[ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]
[ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]
[ 31.745246] [ T2289] platform_probe+0x98/0xe0
[ 31.745254] [ T2289] really_probe+0x144/0x3f8
[ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180
[ 31.745261] [ T2289] driver_probe_device+0x54/0x268
[ 31.745264] [ T2289] __driver_attach+0x11c/0x288
[ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160
[ 31.745274] [ T2289] driver_attach+0x34/0x50
[ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0
[ 31.745281] [ T2289] driver_register+0x78/0x120
[ 31.745285] [ T2289] __platform_driver_register+0x30/0x48
[ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]
[ 31.745298] [ T2289] do_one_initcall+0x11c/0x438
[ 31.745303] [ T2289] do_init_module+0x68/0x228
[ 31.745311] [ T2289] load_module+0x118c/0x13a8
[ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390
[ 31.745320] [ T2289] invoke_syscall+0x74/0x108
[ 31.745326] [ T2289] el0_svc_common+0x90/0xf8
[ 31.745330] [ T2289] do_el0_svc+0x2c/0x48
[ 31.745333] [ T2289] el0_svc+0x60/0x150
[ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118
[ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0
Changes replaces smp_processor_id() with raw_smp_processor_id() to
ensure safe CPU ID retrieval in preemptible contexts. |
| An Unimplemented or Unsupported Feature in UI vulnerability in the CLI of Juniper Networks Junos OS Evolved on QFX5000 Series allows an unauthenticated, adjacent attacker to cause a Denial-of-Service (DoS).
Several configuration statements meant to enforce limits on MAC learning and moves can be configured but do not take effect. This can lead to control plane overload situations which will severely impact the ability of the device to processes legitimate traffic.
This issue affects Junos OS Evolved on QFX5000 Series:
* All versions before 21.4R3-S8-EVO,
* 22.2-EVO versions before 22.2R3-S5-EVO,
* 22.4-EVO versions before 22.4R3-EVO,
* 23.2-EVO versions before 23.2R2-EVO. |
| In the Linux kernel, the following vulnerability has been resolved:
memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe()
The break of for_each_available_child_of_node() needs a
corresponding of_node_put() when the reference 'child' is not
used anymore. Here we do not need to call of_node_put() in
fail path as '!match' means no break.
While the of_platform_device_create() will created a new
reference by 'child' but it has considered the refcounting. |
| An attacker may gain unauthorized access to the host filesystem, potentially allowing them to read and modify system data. |
| An attacker with limited permissions may still be able to write files to specific locations on the device, potentially leading to system manipulation. |
| An attacker with low privileges may be able to trigger critical system functions such as reboot or factory reset without proper restrictions, potentially leading to service disruption or loss of configuration. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Initialize the chan_stats array to zero
The adapter->chan_stats[] array is initialized in
mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out
memory. The array is filled in mwifiex_update_chan_statistics()
and then the user can query the data in mwifiex_cfg80211_dump_survey().
There are two potential issues here. What if the user calls
mwifiex_cfg80211_dump_survey() before the data has been filled in.
Also the mwifiex_update_chan_statistics() function doesn't necessarily
initialize the whole array. Since the array was not initialized at
the start that could result in an information leak.
Also this array is pretty small. It's a maximum of 900 bytes so it's
more appropriate to use kcalloc() instead vmalloc(). |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind
When unbinding pasid - a race condition exists vs outstanding page faults.
To prevent this, the pasid_state object contains a refcount.
* set to 1 on pasid bind
* incremented on each ppr notification start
* decremented on each ppr notification done
* decremented on pasid unbind
Since refcount_dec assumes that refcount will never reach 0:
the current implementation causes the following to be invoked on
pasid unbind:
REFCOUNT_WARN("decrement hit 0; leaking memory")
Fix this issue by changing refcount_dec to refcount_dec_and_test
to explicitly handle refcount=1. |
| Dell PowerProtect Data Domain with Data Domain Operating System (DD OS) versions prior to 8.3.0.15 contain an Insufficient Granularity of Access Control vulnerability. An authenticated user from a trusted remote client could exploit this vulnerability to execute arbitrary commands with root privileges. |
| BlackSheep is an asynchronous web framework to build event based web applications with Python. Prior to 2.4.6, the HTTP Client implementation in BlackSheep is vulnerable to CRLF injection. Missing headers validation makes it possible for an attacker to modify the HTTP requests (e.g. insert a new header) or even create a new HTTP request. Exploitation requires developers to pass unsanitized user input directly into headers.The server part is not affected because BlackSheep delegates to an underlying ASGI server handling of response headers. This vulnerability is fixed in 2.4.6. |
| Improper service binding configuration in internal service components in HCL BigFix IVR version 4.2 allows a privileged attacker to impact service availability via exposure of administrative services bound to external network interfaces instead of the local authentication interface. |
| In the Linux kernel, the following vulnerability has been resolved:
memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings()
We should add the of_node_put() when breaking out of
for_each_child_of_node() as it will automatically increase
and decrease the refcount. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/rockchip: lvds: fix PM usage counter unbalance in poweron
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
We fix it by replacing it with the newest pm_runtime_resume_and_get
to keep usage counter balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
net: rose: include node references in rose_neigh refcount
Current implementation maintains two separate reference counting
mechanisms: the 'count' field in struct rose_neigh tracks references from
rose_node structures, while the 'use' field (now refcount_t) tracks
references from rose_sock.
This patch merges these two reference counting systems using 'use' field
for proper reference management. Specifically, this patch adds incrementing
and decrementing of rose_neigh->use when rose_neigh->count is incremented
or decremented.
This patch also modifies rose_rt_free(), rose_rt_device_down() and
rose_clear_route() to properly release references to rose_neigh objects
before freeing a rose_node through rose_remove_node().
These changes ensure rose_neigh structures are properly freed only when
all references, including those from rose_node structures, are released.
As a result, this resolves a slab-use-after-free issue reported by Syzbot. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: tegra20: Fix refcount leak in tegra20_clock_init
of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: tegra: Fix refcount leak in tegra210_clock_init
of_find_matching_node() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: core: Fix refcount error in del_mtd_device()
del_mtd_device() will call of_node_put() to mtd_get_of_node(mtd), which
is mtd->dev.of_node. However, memset(&mtd->dev, 0) is called before
of_node_put(). As the result, of_node_put() won't do anything in
del_mtd_device(), and causes the refcount leak.
del_mtd_device()
memset(&mtd->dev, 0, sizeof(mtd->dev) # clear mtd->dev
of_node_put()
mtd_get_of_node(mtd) # mtd->dev is cleared, can't locate of_node
# of_node_put(NULL) won't do anything
Fix the error by caching the pointer of the device_node.
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry: attach
overlay node /spi/spi-sram@0
CPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54
0d8a1edddf51f172ff5226989a7565c6313b08e2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x67/0x83
kobject_get+0x155/0x160
of_node_get+0x1f/0x30
of_fwnode_get+0x43/0x70
fwnode_handle_get+0x54/0x80
fwnode_get_nth_parent+0xc9/0xe0
fwnode_full_name_string+0x3f/0xa0
device_node_string+0x30f/0x750
pointer+0x598/0x7a0
vsnprintf+0x62d/0x9b0
...
cfs_overlay_release+0x30/0x90
config_item_release+0xbe/0x1a0
config_item_put+0x5e/0x80
configfs_rmdir+0x3bd/0x540
vfs_rmdir+0x18c/0x320
do_rmdir+0x198/0x330
__x64_sys_rmdir+0x2c/0x40
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
[<miquel.raynal@bootlin.com>: Light reword of the commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()
As comment of pci_get_device() says, it returns a pci_device with its
refcount increased. We need to call pci_dev_put() to decrease the
refcount. Save the return value of pci_get_device() and call
pci_dev_put() to decrease the refcount. |
