Page 16 of 5181 results (0.007 seconds)

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in the remove function. Add the missing call. In the Linux kernel, the following vulnerability has been resolved: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in... • https://git.kernel.org/stable/c/3bdcced41936b054470639c6a76ae033df1074e3 •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-glue: fix memory leak when register device fail If device_register() fails, it should call put_device() to give up reference, the name allocated in dev_set_name() can be freed in callback function kobject_cleanup(). In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-glue: fix memory leak when register device fail If device_register() fails, it should call put_device() to give up... • https://git.kernel.org/stable/c/5b65781d06ea90ef2f8e51a13352c43c3daa8cdc •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: lapbether: fix issue of invalid opcode in lapbeth_open() If lapb_register() failed when lapb device goes to up for the first time, the NAPI is not disabled. As a result, the invalid opcode issue is reported when the lapb device goes to up for the second time. The stack info is as follows: [ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442! [ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN [ 1958.315979][T11356] R... • https://git.kernel.org/stable/c/514e1150da9cd8d7978d990a353636cf1a7a87c2 •

CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix SQE threshold checking Current way of checking available SQE count which is based on HW updated SQB count could result in driver submitting an SQE even before CQE for the previously transmitted SQE at the same index is processed in NAPI resulting losing SKB pointers, hence a leak. Fix this by checking a consumer index which is updated once CQE is processed. In the Linux kernel, the following vulnerability has been resolved... • https://git.kernel.org/stable/c/3ca6c4c882a7f34085b170d93cf0d0e843aa00e6 •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init() When prestera_sdma_switch_init() failed, the memory pointed to by sw->rxtx isn't released. Fix it. Only be compiled, not be tested. In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init() When prestera_sdma_switch_init() failed, the memory pointed to by sw->rxtx isn't released. Fix it. • https://git.kernel.org/stable/c/501ef3066c89d7f9045315e1be58749cf9e6814d •

CVSS: 7.1EPSS: 0%CPEs: 1EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: tun: call napi_schedule_prep() to ensure we own a napi A recent patch exposed another issue in napi_get_frags() caught by syzbot [1] Before feeding packets to GRO, and calling napi_complete() we must first grab NAPI_STATE_SCHED. [1] WARNING: CPU: 0 PID: 3612 at net/core/dev.c:6076 napi_complete_done+0x45b/0x880 net/core/dev.c:6076 Modules linked in: CPU: 0 PID: 3612 Comm: syz-executor408 Not tainted 6.1.0-rc3-syzkaller-00175-g1118b2049... • https://git.kernel.org/stable/c/07d120aa33cc9d9115753d159f64d20c94458781 •

CVSS: 5.6EPSS: 0%CPEs: 3EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg ipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to obtain the wwan power state configuration from BIOS but is not freeing the acpi_object. The acpi_evaluate_dsm() returned acpi_object to be freed. Free the acpi_object after use. In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg ipc_pcie_read_bios_... • https://git.kernel.org/stable/c/7e98d785ae6184c7580a33619dae8b651769ff08 •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: mctp: Fix an error handling path in mctp_init() If mctp_neigh_init() return error, the routes resources should be released in the error handling path. Otherwise some resources leak. In the Linux kernel, the following vulnerability has been resolved: mctp: Fix an error handling path in mctp_init() If mctp_neigh_init() return error, the routes resources should be released in the error handling path. Otherwise some resources leak. • https://git.kernel.org/stable/c/4d8b9319282ae84f5a17b28d8b5b5d1e7e537312 •

CVSS: 8.5EPSS: 0%CPEs: 8EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: macvlan: fix memory leaks of macvlan_common_newlink kmemleak reports memory leaks in macvlan_common_newlink, as follows: ip link add link eth0 name .. type macvlan mode source macaddr add kmemleak reports: unreferenced object 0xffff8880109bb140 (size 64): comm "ip", pid 284, jiffies 4294986150 (age 430.108s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z..... 80 1b fa 0d 80 88 ff ff 1e... • https://git.kernel.org/stable/c/aa5fd0fb77486b8a6764ead8627baa14790e4280 •

CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: riscv: process: fix kernel info leakage thread_struct's s[12] may contain random kernel memory content, which may be finally leaked to userspace. This is a security hole. Fix it by clearing the s[12] array in thread_struct when fork. As for kthread case, it's better to clear the s[12] array as well. In the Linux kernel, the following vulnerability has been resolved: riscv: process: fix kernel info leakage thread_struct's s[12] may contain r... • https://git.kernel.org/stable/c/7db91e57a0acde126a162ababfb1e0ab190130cb •