| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: imx-jpeg: Cleanup after an allocation error
When allocation failures are not cleaned up by the driver, further
allocation errors will be false-positives, which will cause buffers to
remain uninitialized and cause NULL pointer dereferences.
Ensure proper cleanup of failed allocations to prevent these issues. |
| In the Linux kernel, the following vulnerability has been resolved:
media: cxusb: no longer judge rbuf when the write fails
syzbot reported a uninit-value in cxusb_i2c_xfer. [1]
Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()
succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()
will be executed to read rlen bytes of data from the dvb device into the
rbuf.
In this case, although rlen is 1, the write operation failed which resulted
in the dvb read operation not being executed, and ultimately variable i was
not initialized.
[1]
BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]
BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196
cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]
cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196
__i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1
i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315
i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343
i2c_master_send include/linux/i2c.h:109 [inline]
i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183
do_loop_readv_writev fs/read_write.c:848 [inline]
vfs_writev+0x963/0x14e0 fs/read_write.c:1057
do_writev+0x247/0x5c0 fs/read_write.c:1101
__do_sys_writev fs/read_write.c:1169 [inline]
__se_sys_writev fs/read_write.c:1166 [inline]
__x64_sys_writev+0x98/0xe0 fs/read_write.c:1166
x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f |
| RiteCMS v3.1.0 was discovered to use insecure encryption to store passwords. |
| RiteCMS v3.1.0 was discovered to contain an authenticated remote code execution (RCE) vulnerability via the parse_special_tags() function. |
| ChurchCRM is an open-source church management system. Prior to version 5.21.0, a pre-authentication remote code execution vulnerability in ChurchCRM's setup wizard allows unauthenticated attackers to inject arbitrary PHP code during the initial installation process, leading to complete server compromise. The vulnerability exists in `setup/routes/setup.php` where user input from the setup form is directly concatenated into a PHP configuration template without any validation or sanitization. Any parameter in the setup form can be used to inject PHP code that gets written to `Include/Config.php`, which is then executed on every page load. This is more severe than typical authenticated RCE vulnerabilities because it requires no credentials and affects the installation process that administrators must complete. Version 5.21.0 patches the issue. |
| ChurchCRM is an open-source church management system. In versions prior to 6.5.3, the Database Restore functionality does not validate the content or file extension of uploaded files. As a result, an attacker can upload a web shell file and subsequently upload a .htaccess file to enable direct access to it. Once accessed, the uploaded web shell allows remote code execution (RCE) on the server. Version 6.5.3 fixes the issue. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: nand: ecc-mxic: Fix use of uninitialized variable ret
If ctx->steps is zero, the loop processing ECC steps is skipped,
and the variable ret remains uninitialized. It is later checked
and returned, which leads to undefined behavior and may cause
unpredictable results in user space or kernel crashes.
This scenario can be triggered in edge cases such as misconfigured
geometry, ECC engine misuse, or if ctx->steps is not validated
after initialization.
Initialize ret to zero before the loop to ensure correct and safe
behavior regardless of the ctx->steps value.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
| Pi-hole Admin Interface is a web interface for managing Pi-hole, a network-level advertisement and internet tracker blocking application. Pi-hole Admin Interface before 6.3 is vulnerable to Carriage Return Line Feed (CRLF) injection. When a request is made to a file ending with the .lp extension, the application performs a redirect without properly sanitizing the input. An attacker can inject carriage return and line feed characters (%0d%0a) to manipulate both the headers and the content of the HTTP response. This enables the injection of arbitrary HTTP response headers, potentially leading to session fixation, cache poisoning, and the weakening or bypassing of browser-based security mechanisms such as Content Security Policy or X-XSS-Protection. This vulnerability is fixed in 6.3. |
| In the Linux kernel, the following vulnerability has been resolved:
powerpc/fixmap: Fix VM debug warning on unmap
Unmapping a fixmap entry is done by calling __set_fixmap()
with FIXMAP_PAGE_CLEAR as flags.
Today, powerpc __set_fixmap() calls map_kernel_page().
map_kernel_page() is not happy when called a second time
for the same page.
WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8
CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682
NIP: c0017cd4 LR: c00187f0 CTR: 00000010
REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty)
MSR: 00029032 <EE,ME,IR,DR,RI> CR: 42000208 XER: 00000000
GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c
GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000
NIP [c0017cd4] set_pte_at+0xc/0x1e8
LR [c00187f0] map_kernel_page+0x9c/0x100
Call Trace:
[e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable)
[e1011e30] [c0165fec] __set_fixmap+0x30/0x44
[e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170
[e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0
[e1011e90] [c0c03634] do_one_initcall+0x80/0x178
[e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250
[e1011f20] [c0007e34] kernel_init+0x24/0x140
[e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010
4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030
Implement unmap_kernel_page() which clears an existing pte. |
| In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: Fix sleeping function called from invalid context
The driver can call card->isac.release() function from an atomic
context.
Fix this by calling this function after releasing the lock.
The following log reveals it:
[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
[ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
[ 44.169574 ] INFO: lockdep is turned off.
[ 44.169899 ] irq event stamp: 0
[ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00
[ 44.171240 ] softirqs last enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00
[ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0
[ 44.172318 ] Preemption disabled at:
[ 44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet]
[ 44.174441 ] Call Trace:
[ 44.174630 ] dump_stack_lvl+0xa8/0xd1
[ 44.174912 ] dump_stack+0x15/0x17
[ 44.175166 ] ___might_sleep+0x3a2/0x510
[ 44.175459 ] ? nj_release+0x69/0x500 [netjet]
[ 44.175791 ] __might_sleep+0x82/0xe0
[ 44.176063 ] ? start_flush_work+0x20/0x7b0
[ 44.176375 ] start_flush_work+0x33/0x7b0
[ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170
[ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0
[ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0
[ 44.177711 ] __flush_work+0x11a/0x1a0
[ 44.177991 ] ? flush_work+0x20/0x20
[ 44.178257 ] ? lock_release+0x13c/0x8f0
[ 44.178550 ] ? __kasan_check_write+0x14/0x20
[ 44.178872 ] ? do_raw_spin_lock+0x148/0x360
[ 44.179187 ] ? read_lock_is_recursive+0x20/0x20
[ 44.179530 ] ? __kasan_check_read+0x11/0x20
[ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900
[ 44.180168 ] ? ____kasan_slab_free+0x116/0x140
[ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60
[ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0
[ 44.181189 ] ? kfree+0x13e/0x290
[ 44.181438 ] flush_work+0x17/0x20
[ 44.181695 ] mISDN_freedchannel+0xe8/0x100
[ 44.182006 ] isac_release+0x210/0x260 [mISDNipac]
[ 44.182366 ] nj_release+0xf6/0x500 [netjet]
[ 44.182685 ] nj_remove+0x48/0x70 [netjet]
[ 44.182989 ] pci_device_remove+0xa9/0x250 |
| In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-core: explicitly clear ioctl input data
As seen from a recent syzbot bug report, mistakes in the compat ioctl
implementation can lead to uninitialized kernel stack data getting used
as input for driver ioctl handlers.
The reported bug is now fixed, but it's possible that other related
bugs are still present or get added in the future. As the drivers need
to check user input already, the possible impact is fairly low, but it
might still cause an information leak.
To be on the safe side, always clear the entire ioctl buffer before
calling the conversion handler functions that are meant to initialize
them. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu: Fix arm_smmu_device refcount leak when arm_smmu_rpm_get fails
arm_smmu_rpm_get() invokes pm_runtime_get_sync(), which increases the
refcount of the "smmu" even though the return value is less than 0.
The reference counting issue happens in some error handling paths of
arm_smmu_rpm_get() in its caller functions. When arm_smmu_rpm_get()
fails, the caller functions forget to decrease the refcount of "smmu"
increased by arm_smmu_rpm_get(), causing a refcount leak.
Fix this issue by calling pm_runtime_resume_and_get() instead of
pm_runtime_get_sync() in arm_smmu_rpm_get(), which can keep the refcount
balanced in case of failure. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: aardvark: Fix kernel panic during PIO transfer
Trying to start a new PIO transfer by writing value 0 in PIO_START register
when previous transfer has not yet completed (which is indicated by value 1
in PIO_START) causes an External Abort on CPU, which results in kernel
panic:
SError Interrupt on CPU0, code 0xbf000002 -- SError
Kernel panic - not syncing: Asynchronous SError Interrupt
To prevent kernel panic, it is required to reject a new PIO transfer when
previous one has not finished yet.
If previous PIO transfer is not finished yet, the kernel may issue a new
PIO request only if the previous PIO transfer timed out.
In the past the root cause of this issue was incorrectly identified (as it
often happens during link retraining or after link down event) and special
hack was implemented in Trusted Firmware to catch all SError events in EL3,
to ignore errors with code 0xbf000002 and not forwarding any other errors
to kernel and instead throw panic from EL3 Trusted Firmware handler.
Links to discussion and patches about this issue:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541
But the real cause was the fact that during link retraining or after link
down event the PIO transfer may take longer time, up to the 1.44s until it
times out. This increased probability that a new PIO transfer would be
issued by kernel while previous one has not finished yet.
After applying this change into the kernel, it is possible to revert the
mentioned TF-A hack and SError events do not have to be caught in TF-A EL3. |
| Aqara Hub devices including Camera Hub G3 4.1.9_0027, Hub M2 4.3.6_0027, and Hub M3 4.3.6_0025 contain an undocumented remote access mechanism enabling unrestricted remote command execution. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: renesas_usbhs: Reorder clock handling and power management in probe
Reorder the initialization sequence in `usbhs_probe()` to enable runtime
PM before accessing registers, preventing potential crashes due to
uninitialized clocks.
Currently, in the probe path, registers are accessed before enabling the
clocks, leading to a synchronous external abort on the RZ/V2H SoC.
The problematic call flow is as follows:
usbhs_probe()
usbhs_sys_clock_ctrl()
usbhs_bset()
usbhs_write()
iowrite16() <-- Register access before enabling clocks
Since `iowrite16()` is performed without ensuring the required clocks are
enabled, this can lead to access errors. To fix this, enable PM runtime
early in the probe function and ensure clocks are acquired before register
access, preventing crashes like the following on RZ/V2H:
[13.272640] Internal error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP
[13.280814] Modules linked in: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6
[13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98
[13.296640] Hardware name: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT)
[13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs]
[13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs]
[13.321138] sp : ffff8000827e3850
[13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0
[13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025
[13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010
[13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff
[13.352895] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000827e36ce
[13.360009] x14: 00000000000003d7 x13: 00000000000003d7 x12: 0000000000000000
[13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9 : ffff8000827e3750
[13.374235] x8 : ffff0000c1850b00 x7 : 0000000003826060 x6 : 000000000000001c
[13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000
[13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080
[13.395574] Call trace:
[13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P)
[13.403076] platform_probe+0x68/0xdc
[13.406738] really_probe+0xbc/0x2c0
[13.410306] __driver_probe_device+0x78/0x120
[13.414653] driver_probe_device+0x3c/0x154
[13.418825] __driver_attach+0x90/0x1a0
[13.422647] bus_for_each_dev+0x7c/0xe0
[13.426470] driver_attach+0x24/0x30
[13.430032] bus_add_driver+0xe4/0x208
[13.433766] driver_register+0x68/0x130
[13.437587] __platform_driver_register+0x24/0x30
[13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs]
[13.448450] do_one_initcall+0x60/0x1d4
[13.452276] do_init_module+0x54/0x1f8
[13.456014] load_module+0x1754/0x1c98
[13.459750] init_module_from_file+0x88/0xcc
[13.464004] __arm64_sys_finit_module+0x1c4/0x328
[13.468689] invoke_syscall+0x48/0x104
[13.472426] el0_svc_common.constprop.0+0xc0/0xe0
[13.477113] do_el0_svc+0x1c/0x28
[13.480415] el0_svc+0x30/0xcc
[13.483460] el0t_64_sync_handler+0x10c/0x138
[13.487800] el0t_64_sync+0x198/0x19c
[13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084)
[13.497522] ---[ end trace 0000000000000000 ]--- |
| Anyscale Ray 2.6.3 and 2.8.0 allows a remote attacker to execute arbitrary code via the job submission API. NOTE: the vendor's position is that this report is irrelevant because Ray, as stated in its documentation, is not intended for use outside of a strictly controlled network environment. (Also, within that environment, customers at version 2.52.0 and later can choose to use token authentication.) |
| In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call
mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()
utilises a local buffer called "buff", which is initialised
with control_read(). However "buff" is conditionally
initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then
"buff" remains uninitialised. Once this happens the
uninitialised "buff" is accessed and returned during
ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read()
ignores the return value of control_read(), leading to
uinit-access of "buff".
To fix this we should check the return value of
control_read() and return early on error. |
| Server-Side Template Injection (SSTI) vulnerability in inducer relate before v.2024.1 allows a remote attacker to execute arbitrary code via a crafted payload to the Batch-Issue Exam Tickets function. |
| Before Beetl v3.15.12, the rendering template has a server-side template injection (SSTI) vulnerability. When the incoming template is controllable, it will be filtered by the DefaultNativeSecurityManager blacklist. Because blacklist filtering is not strict, the blacklist can be bypassed, leading to arbitrary code execution. |
| In grav <1.7.49.5, a SSRF (Server-Side Request Forgery) vector may be triggered via Twig templates when page content is processed by Twig and the configuration allows undefined PHP functions to be registered |
