Page 107 of 4023 results (0.014 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe() During driver initialization, the pointer of card info, i.e. the variable 'ci' is required. However, the definition of 'com20020pci_id_table' reveals that this field is empty for some devices, which will cause null pointer dereference when initializing these devices. The following log reveals it: [ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci] [ 3.975181] Call Trace: [ 3.976208] local_pci_probe+0x13f/0x210 [ 3.977248] pci_device_probe+0x34c/0x6d0 [ 3.977255] ? pci_uevent+0x470/0x470 [ 3.978265] really_probe+0x24c/0x8d0 [ 3.978273] __driver_probe_device+0x1b3/0x280 [ 3.979288] driver_probe_device+0x50/0x370 Fix this by checking whether the 'ci' is a null pointer first. • https://git.kernel.org/stable/c/8c14f9c70327a6fb75534c4c61d7ea9c82ccf78f https://git.kernel.org/stable/c/8e3bc7c5bbf87e86e9cd652ca2a9166942d86206 https://git.kernel.org/stable/c/b1ee6b9340a38bdb9e5c90f0eac5b22b122c3049 https://git.kernel.org/stable/c/b838add93e1dd98210482dc433768daaf752bdef https://git.kernel.org/stable/c/e50c589678e50f8d574612e473ca60ef45190896 https://git.kernel.org/stable/c/5f394102ee27dbf051a4e283390cd8d1759dacea https://git.kernel.org/stable/c/ea372aab54903310756217d81610901a8e66cb7d https://git.kernel.org/stable/c/ca0bdff4249a644f2ca7a49d410d95b8d •

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

In the Linux kernel, the following vulnerability has been resolved: auxdisplay: lcd2s: Fix memory leak in ->remove() Once allocated the struct lcd2s_data is never freed. Fix the memory leak by switching to devm_kzalloc(). • https://git.kernel.org/stable/c/8c9108d014c5bd0f0da2e3544eb45dc56a6da92b https://git.kernel.org/stable/c/5d53cd33f4253aa4cf02bf7e670b3c6a99674351 https://git.kernel.org/stable/c/3585ed5f9b11a6094dd991d76a1541e5d03b986a https://git.kernel.org/stable/c/898c0a15425a5bcaa8d44bd436eae5afd2483796 •

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

In the Linux kernel, the following vulnerability has been resolved: mptcp: Correctly set DATA_FIN timeout when number of retransmits is large Syzkaller with UBSAN uncovered a scenario where a large number of DATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN timeout calculation: ================================================================================ UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: events mptcp_worker Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330 mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline] __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445 mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528 process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307 worker_thread+0x95/0xe10 kernel/workqueue.c:2454 kthread+0x2f4/0x3b0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> ================================================================================ This change limits the maximum timeout by limiting the size of the shift, which keeps all intermediate values in-bounds. • https://git.kernel.org/stable/c/6477dd39e62c3a67cfa368ddc127410b4ae424c6 https://git.kernel.org/stable/c/0af76111c2a6326e4bb56f64a6e453c6ec6dd2da https://git.kernel.org/stable/c/0c3f34beb459753f9f80d0cc14c1b50ab615c631 https://git.kernel.org/stable/c/03ae283bd71f761feae3f402668d698b393b0e79 https://git.kernel.org/stable/c/877d11f0332cd2160e19e3313e262754c321fa36 •

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

In the Linux kernel, the following vulnerability has been resolved: ibmvnic: free reset-work-item when flushing Fix a tiny memory leak when flushing the reset work queue. A memory leak flaw was found in the Linux kernel’s IBM Virtual Network Interface Controller (ibmvnic ) driver. This issue involved not properly freeing memory associated with a reset work item when the reset work queue is flushed, causing the reset-work-item not to be deallocated. This flaw allows an attacker with control over the virtual NIC to repeatedly trigger interface resets to cause small amounts of memory to leak. Over time, this can lead to memory exhaustion, especially in systems already resource-constrained or under heavy load, resulting in a possible denial of service (DoS) condition. • https://git.kernel.org/stable/c/2770a7984db588913e11a6dfcfe3461dbba9b7b2 https://git.kernel.org/stable/c/786576c03b313a9ff6585458aa0dfd039d897f51 https://git.kernel.org/stable/c/58b07100c20e95c78b8cb4d6d28ca53eb9ef81f2 https://git.kernel.org/stable/c/6acbc8875282d3ca8a73fa93cd7a9b166de5019c https://git.kernel.org/stable/c/39738a2346b270e8f72f88d8856de2c167bd2899 https://git.kernel.org/stable/c/4c26745e4576cec224092e6cc12e37829333b183 https://git.kernel.org/stable/c/8d0657f39f487d904fca713e0bc39c2707382553 https://access.redhat.com/security/cve/CVE-2022-48905 • CWE-401: Missing Release of Memory after Effective Lifetime •

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

In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix I/O page table memory leak The current logic updates the I/O page table mode for the domain before calling the logic to free memory used for the page table. This results in IOMMU page table memory leak, and can be observed when launching VM w/ pass-through devices. Fix by freeing the memory used for page table before updating the mode. • https://git.kernel.org/stable/c/e42ba0633064ef23eb1c8c21edf96bac1541bd4b https://git.kernel.org/stable/c/378e2fe1eb58d5c2ed55c8fe5e11f9db5033cdd6 https://git.kernel.org/stable/c/c78627f757e37c2cf386b59c700c4e1574988597 https://git.kernel.org/stable/c/6b0b2d9a6a308bcd9300c2d83000a82812c56cea •