| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Tanium addressed a SQL injection vulnerability in Asset. |
| Tanium addressed an improper access controls vulnerability in Tanium Server. |
| Tanium addressed an improper access controls vulnerability in Interact. |
| A vulnerability has been found in WeKan up to 8.20. Affected by this vulnerability is the function ComprehensiveBoardMigration of the file server/migrations/comprehensiveBoardMigration.js of the component Migration Operation Handler. The manipulation of the argument boardId leads to improper access controls. The attack is possible to be carried out remotely. Upgrading to version 8.21 addresses this issue. The identifier of the patch is cc35dafef57ef6e44a514a523f9a8d891e74ad8f. Upgrading the affected component is advised. |
| Improper access control in InputManager to SMR Apr-2025 Release 1 allows local attackers to access the scancode of specific input device. |
| A vulnerability was found in WeKan up to 8.20. Affected by this issue is some unknown functionality of the file server/methods/positionHistory.js of the component Position-History Tracking. The manipulation results in missing authorization. The attack may be performed from remote. Upgrading to version 8.21 can resolve this issue. The patch is identified as 55576ec17722db094835470b386162c9a662fb60. It is advisable to upgrade the affected component. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix pci device refcount leak in ppr_notifier()
As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put(). So call it before returning from ppr_notifier()
to avoid refcount leak. |
| In the Linux kernel, the following vulnerability has been resolved:
drbd: only clone bio if we have a backing device
Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a
bio_set_dev call (which has since been removed) to "earlier", from
drbd_request_prepare to drbd_req_new.
The problem is that this accesses device->ldev->backing_bdev, which is
not NULL-checked at this point. When we don't have an ldev (i.e. when
the DRBD device is diskless), this leads to a null pointer deref.
So, only allocate the private_bio if we actually have a disk. This is
also a small optimization, since we don't clone the bio to only to
immediately free it again in the diskless case. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate data run offset
This adds sanity checks for data run offset. We should make sure data
run offset is legit before trying to unpack them, otherwise we may
encounter use-after-free or some unexpected memory access behaviors.
[ 82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570
[ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240
[ 82.941670]
[ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15
[ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 82.943720] Call Trace:
[ 82.944204] <TASK>
[ 82.944471] dump_stack_lvl+0x49/0x63
[ 82.944908] print_report.cold+0xf5/0x67b
[ 82.945141] ? __wait_on_bit+0x106/0x120
[ 82.945750] ? run_unpack+0x2e3/0x570
[ 82.946626] kasan_report+0xa7/0x120
[ 82.947046] ? run_unpack+0x2e3/0x570
[ 82.947280] __asan_load1+0x51/0x60
[ 82.947483] run_unpack+0x2e3/0x570
[ 82.947709] ? memcpy+0x4e/0x70
[ 82.947927] ? run_pack+0x7a0/0x7a0
[ 82.948158] run_unpack_ex+0xad/0x3f0
[ 82.948399] ? mi_enum_attr+0x14a/0x200
[ 82.948717] ? run_unpack+0x570/0x570
[ 82.949072] ? ni_enum_attr_ex+0x1b2/0x1c0
[ 82.949332] ? ni_fname_type.part.0+0xd0/0xd0
[ 82.949611] ? mi_read+0x262/0x2c0
[ 82.949970] ? ntfs_cmp_names_cpu+0x125/0x180
[ 82.950249] ntfs_iget5+0x632/0x1870
[ 82.950621] ? ntfs_get_block_bmap+0x70/0x70
[ 82.951192] ? evict+0x223/0x280
[ 82.951525] ? iput.part.0+0x286/0x320
[ 82.951969] ntfs_fill_super+0x1321/0x1e20
[ 82.952436] ? put_ntfs+0x1d0/0x1d0
[ 82.952822] ? vsprintf+0x20/0x20
[ 82.953188] ? mutex_unlock+0x81/0xd0
[ 82.953379] ? set_blocksize+0x95/0x150
[ 82.954001] get_tree_bdev+0x232/0x370
[ 82.954438] ? put_ntfs+0x1d0/0x1d0
[ 82.954700] ntfs_fs_get_tree+0x15/0x20
[ 82.955049] vfs_get_tree+0x4c/0x130
[ 82.955292] path_mount+0x645/0xfd0
[ 82.955615] ? putname+0x80/0xa0
[ 82.955955] ? finish_automount+0x2e0/0x2e0
[ 82.956310] ? kmem_cache_free+0x110/0x390
[ 82.956723] ? putname+0x80/0xa0
[ 82.957023] do_mount+0xd6/0xf0
[ 82.957411] ? path_mount+0xfd0/0xfd0
[ 82.957638] ? __kasan_check_write+0x14/0x20
[ 82.957948] __x64_sys_mount+0xca/0x110
[ 82.958310] do_syscall_64+0x3b/0x90
[ 82.958719] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 82.959341] RIP: 0033:0x7fd0d1ce948a
[ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008
[ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
[ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a
[ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0
[ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020
[ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0
[ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt76x0: fix oob access in mt76x0_phy_get_target_power
After 'commit ba45841ca5eb ("wifi: mt76: mt76x02: simplify struct
mt76x02_rate_power")', mt76x02 relies on ht[0-7] rate_power data for
vht mcs{0,7}, while it uses vth[0-1] rate_power for vht mcs {8,9}.
Fix a possible out-of-bound access in mt76x0_phy_get_target_power routine. |
| Improper Verification of Intent by Broadcast Receiver in DeviceIdService prior to SMR Apr-2025 Release 1 allows local attackers to reset OAID. |
| Out-of-bounds write in secfr trustlet prior to SMR Apr-2025 Release 1 allows local privileged attackers to cause memory corruption. |
| A vulnerability was discovered in RISC-V Rocket-Chip v1.6 and before implementation where the SRET (Supervisor-mode Exception Return) instruction fails to correctly transition the processor's privilege level. Instead of downgrading from Machine-mode (M-mode) to Supervisor-mode (S-mode) as specified by the sstatus.SPP bit, the processor incorrectly remains in M-mode, leading to a critical privilege retention vulnerability. |
| In the Linux kernel, the following vulnerability has been resolved:
media: coda: Add check for kmalloc
As the kmalloc may return NULL pointer,
it should be better to check the return value
in order to avoid NULL poineter dereference,
same as the others. |
| A vulnerability was determined in WeKan up to 8.20. This affects an unknown part of the file packages/wekan-ldap/server/syncUser.js of the component LDAP User Sync. This manipulation causes improper access controls. It is possible to initiate the attack remotely. Upgrading to version 8.21 is able to mitigate this issue. Patch name: 146905a459106b5d00b4f09453a6554255e6965a. You should upgrade the affected component. |
| In the Linux kernel, the following vulnerability has been resolved:
perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init()
arm_smmu_pmu_init() won't remove the callback added by
cpuhp_setup_state_multi() when platform_driver_register() failed. Remove
the callback by cpuhp_remove_multi_state() in fail path.
Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:
arm-ccn: Prevent hotplug callback leak") |
| In the Linux kernel, the following vulnerability has been resolved:
lib/fonts: fix undefined behavior in bit shift for get_default_font
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20
left shift of 1 by 31 places cannot be represented in type 'int'
<TASK>
dump_stack_lvl+0x7d/0xa5
dump_stack+0x15/0x1b
ubsan_epilogue+0xe/0x4e
__ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
get_default_font+0x1c7/0x1f0
fbcon_startup+0x347/0x3a0
do_take_over_console+0xce/0x270
do_fbcon_takeover+0xa1/0x170
do_fb_registered+0x2a8/0x340
fbcon_fb_registered+0x47/0xe0
register_framebuffer+0x294/0x4a0
__drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]
drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]
drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]
drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]
bochs_pci_probe+0x6ca/0x772 [bochs]
local_pci_probe+0x4d/0xb0
pci_device_probe+0x119/0x320
really_probe+0x181/0x550
__driver_probe_device+0xc6/0x220
driver_probe_device+0x32/0x100
__driver_attach+0x195/0x200
bus_for_each_dev+0xbb/0x120
driver_attach+0x27/0x30
bus_add_driver+0x22e/0x2f0
driver_register+0xa9/0x190
__pci_register_driver+0x90/0xa0
bochs_pci_driver_init+0x52/0x1000 [bochs]
do_one_initcall+0x76/0x430
do_init_module+0x61/0x28a
load_module+0x1f82/0x2e50
__do_sys_finit_module+0xf8/0x190
__x64_sys_finit_module+0x23/0x30
do_syscall_64+0x58/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential memory leak in ext4_fc_record_regions()
As krealloc may return NULL, in this case 'state->fc_regions' may not be
freed by krealloc, but 'state->fc_regions' already set NULL. Then will
lead to 'state->fc_regions' memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()
In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocated
in failure, then `pcmdpriv->cmd_allocated_buf` will be not properly
released. Besides, considering there are only two error paths and the
first one can directly return, so we do not need implicitly jump to the
`exit` tag to execute the error handler.
So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the error
path to release the resource and simplified the return logic of
rtw_init_cmd_priv(). As there is no proper device to test with, no runtime
testing was performed. |
| In the Linux kernel, the following vulnerability has been resolved:
test_firmware: fix memory leak in test_firmware_init()
When misc_register() failed in test_firmware_init(), the memory pointed
by test_fw_config->name is not released. The memory leak information is
as follows:
unreferenced object 0xffff88810a34cb00 (size 32):
comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s)
hex dump (first 32 bytes):
74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi
6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n...............
backtrace:
[<ffffffff81b21fcb>] __kmalloc_node_track_caller+0x4b/0xc0
[<ffffffff81affb96>] kstrndup+0x46/0xc0
[<ffffffffa0403a49>] __test_firmware_config_init+0x29/0x380 [test_firmware]
[<ffffffffa040f068>] 0xffffffffa040f068
[<ffffffff81002c41>] do_one_initcall+0x141/0x780
[<ffffffff816a72c3>] do_init_module+0x1c3/0x630
[<ffffffff816adb9e>] load_module+0x623e/0x76a0
[<ffffffff816af471>] __do_sys_finit_module+0x181/0x240
[<ffffffff89978f99>] do_syscall_64+0x39/0xb0
[<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
