Page 43 of 3854 results (0.008 seconds)

CVSS: 7.5EPSS: 0%CPEs: 5EXPL: 0

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove errant put in error path drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free. In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove errant put in error path drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free. • https://git.kernel.org/stable/c/2194a63a818db71065ebe09c8104f5f021ca4e7b •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing() The SJA1105 family has 45 L2 policing table entries (SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110 (SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but accounting for the difference in port count (5 in SJA1105 vs 10 in SJA1110) does not fully explain the difference. Rather, the SJA1110 also has L2 ingress policers for multicast traffic. If a packet ... • https://git.kernel.org/stable/c/38fbe91f2287c696f290d9115901aa435f7166a8 •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix array index out of bound error in DCN32 DML [Why&How] LinkCapacitySupport array is indexed with the number of voltage states and not the number of max DPPs. Fix the error by changing the array declaration to use the correct (larger) array size of total number of voltage states. In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix array index out of bound error in DCN32 DML [Why&How] L... • https://git.kernel.org/stable/c/3d8a298b2e83b98042e6ec726e934f535b23e6aa •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: HID: core: fix shift-out-of-bounds in hid_report_raw_event Syzbot reported shift-out-of-bounds in hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-r... • https://git.kernel.org/stable/c/dde5845a529ff753364a6d1aea61180946270bfa •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()") we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") the check for dev->type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices cla... • https://git.kernel.org/stable/c/4ac1feff6ea6495cbfd336f4438a6c6d140544a6 •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable_offload: fix using __this_cpu_add in preemptible flow_offload_queue_work() can be called in workqueue without bh disabled, like the call trace showed in my act_ct testing, calling NF_FLOW_TABLE_STAT_INC() there would cause a call trace: BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u4:0/138560 caller is flow_offload_queue_work+0xec/0x1b0 [nf_flow_table] Workqueue: act_ct_workqueue tcf_ct_flow_table... • https://git.kernel.org/stable/c/b038177636f83bbf87c2b238706474145dd2cd04 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_... • https://git.kernel.org/stable/c/159f3cd92f17c61a4e2a47456de5865b114ef88e •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() ... • https://git.kernel.org/stable/c/f942a7de047d8c599cc1a9a26293c8c7400450ea •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add() Kernel fault injection test reports null-ptr-deref as follows: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace: raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0... • https://git.kernel.org/stable/c/fcf39e6e88e9492f6688ec8ba4e1be622b904232 •

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

21 Oct 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix not cleanup led when bt_init fails bt_init() calls bt_leds_init() to register led, but if it fails later, bt_leds_cleanup() is not called to unregister it. This can cause panic if the argument "bluetooth-power" in text is freed and then another led_trigger_register() tries to access it: BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Call Trace: led_trigger_register+0x10d/0x4f0 ... • https://git.kernel.org/stable/c/e64c97b53bc6727aa4385535166aaa047281e02d •