| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Azure Science Virtual Machine (DSVM) Elevation of Privilege Vulnerability |
| Microsoft Dynamics 365 (On-Premises) Information Disclosure Vulnerability |
| Microsoft SharePoint Server Remote Code Execution Vulnerability |
| Windows Cryptographic Services Information Disclosure Vulnerability |
| Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability |
| Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability |
| Windows Standards-Based Storage Management Service Denial of Service Vulnerability |
| Winlogon Elevation of Privilege Vulnerability |
| Winlogon Elevation of Privilege Vulnerability |
| Windows Themes Denial of Service Vulnerability |
| Windows Kernel Elevation of Privilege Vulnerability |
| Windows Standards-Based Storage Management Service Remote Code Execution Vulnerability |
| Microsoft Edge (Chromium-based) Spoofing Vulnerability |
| Microsoft Edge (Chromium-based) Spoofing Vulnerability |
| Windows Container Manager Service Elevation of Privilege Vulnerability |
| Microsoft Event Trace Log File Parsing Remote Code Execution Vulnerability |
| DHCP Server Service Denial of Service Vulnerability |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq27xxx-i2c: Do not free non existing IRQ
The bq27xxx i2c-client may not have an IRQ, in which case
client->irq will be 0. bq27xxx_battery_i2c_probe() already has
an if (client->irq) check wrapping the request_threaded_irq().
But bq27xxx_battery_i2c_remove() unconditionally calls
free_irq(client->irq) leading to:
[ 190.310742] ------------[ cut here ]------------
[ 190.310843] Trying to free already-free IRQ 0
[ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310
Followed by a backtrace when unbinding the driver. Add
an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring
probe() to fix this. |
| In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
| ^
Use the correct type instead here. |
| In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on
PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until
commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")
which invokes smp_call_function_single via qman_update_cgr_safe every
time a link goes up or down. |
