Filtered by vendor Linux
Subscribe
Total
13272 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-27047 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: phy: fix phy_get_internal_delay accessing an empty array The phy_get_internal_delay function could try to access to an empty array in the case that the driver is calling phy_get_internal_delay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >= 0. As there is already delay < 0 test just before, the test could only be size == 0. | |||||
| CVE-2024-27045 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()' Tell snprintf() to store at most 10 bytes in the output buffer instead of 30. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10 | |||||
| CVE-2024-27043 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free. | |||||
| CVE-2024-27042 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()' The issue arises when the array 'adev->vcn.vcn_config' is accessed before checking if the index 'adev->vcn.num_vcn_inst' is within the bounds of the array. The fix involves moving the bounds check before the array access. This ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the array before it is used as an index. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_reg_base_init() error: testing array offset 'adev->vcn.num_vcn_inst' after use. | |||||
| CVE-2024-27033 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to remove unnecessary f2fs_bug_on() to avoid panic verify_blkaddr() will trigger panic once we inject fault into f2fs_is_valid_blkaddr(), fix to remove this unnecessary f2fs_bug_on(). | |||||
| CVE-2024-27051 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE. | |||||
| CVE-2024-27049 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925e: fix use-after-free in free_irq() From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test to make sure the shared irq handler should be able to handle the unexpected event after deregistration. For this case, let's apply MT76_REMOVED flag to indicate the device was removed and do not run into the resource access anymore. | |||||
| CVE-2024-27048 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: wifi: brcm80211: handle pmk_op allocation failure The kzalloc() in brcmf_pmksa_v3_op() will return null if the physical memory has run out. As a result, if we dereference the null value, the null pointer dereference bug will happen. Return -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails for pmk_op. | |||||
| CVE-2024-27046 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nfp: flower: handle acti_netdevs allocation failure The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen. This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again. | |||||
| CVE-2021-47292 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: io_uring: fix memleak in io_init_wq_offload() I got memory leak report when doing fuzz test: BUG: memory leak unreferenced object 0xffff888107310a80 (size 96): comm "syz-executor.6", pid 4610, jiffies 4295140240 (age 20.135s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<000000001974933b>] kmalloc include/linux/slab.h:591 [inline] [<000000001974933b>] kzalloc include/linux/slab.h:721 [inline] [<000000001974933b>] io_init_wq_offload fs/io_uring.c:7920 [inline] [<000000001974933b>] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955 [<0000000039d0800d>] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016 [<000000008482e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [inline] [<000000008482e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline] [<000000008482e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline] [<000000008482e78c>] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301 [<00000000b875f18f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 [<000000006b0a8484>] entry_SYSCALL_64_after_hwframe+0x44/0xae CPU0 CPU1 io_uring_enter io_uring_enter io_uring_add_tctx_node io_uring_add_tctx_node __io_uring_add_tctx_node __io_uring_add_tctx_node io_uring_alloc_task_context io_uring_alloc_task_context io_init_wq_offload io_init_wq_offload hash = kzalloc hash = kzalloc ctx->hash_map = hash ctx->hash_map = hash <- one of the hash is leaked When calling io_uring_enter() in parallel, the 'hash_map' will be leaked, add uring_lock to protect 'hash_map'. | |||||
| CVE-2021-47291 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: fix another slab-out-of-bounds in fib6_nh_flush_exceptions While running the self-tests on a KASAN enabled kernel, I observed a slab-out-of-bounds splat very similar to the one reported in commit 821bbf79fe46 ("ipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions"). We additionally need to take care of fib6_metrics initialization failure when the caller provides an nh. The fix is similar, explicitly free the route instead of calling fib6_info_release on a half-initialized object. | |||||
| CVE-2021-47290 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix NULL dereference on XCOPY completion CPU affinity control added with commit 39ae3edda325 ("scsi: target: core: Make completion affinity configurable") makes target_complete_cmd() queue work on a CPU based on se_tpg->se_tpg_wwn->cmd_compl_affinity state. LIO's EXTENDED COPY worker is a special case in that read/write cmds are dispatched using the global xcopy_pt_tpg, which carries a NULL se_tpg_wwn pointer following initialization in target_xcopy_setup_pt(). The NULL xcopy_pt_tpg->se_tpg_wwn pointer is dereferenced on completion of any EXTENDED COPY initiated read/write cmds. E.g using the libiscsi SCSI.ExtendedCopy.Simple test: BUG: kernel NULL pointer dereference, address: 00000000000001a8 RIP: 0010:target_complete_cmd+0x9d/0x130 [target_core_mod] Call Trace: fd_execute_rw+0x148/0x42a [target_core_file] ? __dynamic_pr_debug+0xa7/0xe0 ? target_check_reservation+0x5b/0x940 [target_core_mod] __target_execute_cmd+0x1e/0x90 [target_core_mod] transport_generic_new_cmd+0x17c/0x330 [target_core_mod] target_xcopy_issue_pt_cmd+0x9/0x60 [target_core_mod] target_xcopy_read_source.isra.7+0x10b/0x1b0 [target_core_mod] ? target_check_fua+0x40/0x40 [target_core_mod] ? transport_complete_task_attr+0x130/0x130 [target_core_mod] target_xcopy_do_work+0x61f/0xc00 [target_core_mod] This fix makes target_complete_cmd() queue work on se_cmd->cpuid if se_tpg_wwn is NULL. | |||||
| CVE-2021-47289 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ACPI: fix NULL pointer dereference Commit 71f642833284 ("ACPI: utils: Fix reference counting in for_each_acpi_dev_match()") started doing "acpi_dev_put()" on a pointer that was possibly NULL. That fails miserably, because that helper inline function is not set up to handle that case. Just make acpi_dev_put() silently accept a NULL pointer, rather than calling down to put_device() with an invalid offset off that NULL pointer. | |||||
| CVE-2021-47288 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf() Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). | |||||
| CVE-2021-47287 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: driver core: auxiliary bus: Fix memory leak when driver_register() fail If driver_register() returns with error we need to free the memory allocated for auxdrv->driver.name before returning from __auxiliary_driver_register() | |||||
| CVE-2021-47298 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix potential memory leak on unlikely error case If skb_linearize is needed and fails we could leak a msg on the error handling. To fix ensure we kfree the msg block before returning error. Found during code review. | |||||
| CVE-2024-27076 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak Free the memory allocated in v4l2_ctrl_handler_init on release. | |||||
| CVE-2024-27077 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name. | |||||
| CVE-2024-27078 | 1 Linux | 1 Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: fix some memleaks in tpg_alloc In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0. | |||||
| CVE-2024-27074 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2024-12-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: go7007: fix a memleak in go7007_load_encoder In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked. | |||||