Page 135 of 2878 results (0.010 seconds)

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ax25: Fix netdev refcount issue The dev_tracker is added to ax25_cb in ax25_bind(). When the ax25 device is detaching, the dev_tracker of ax25_cb should be deallocated in ax25_kill_by_device() instead of the dev_tracker of ax25_dev. The log reported by ref_tracker is shown below: [ 80.884935] ref_tracker: reference already released. [ 80.885150] ref_tracker: allocated in: [ 80.885349] ax25_dev_device_up+0x105/0x540 [ 80.885730] ax25_device_... • https://git.kernel.org/stable/c/feef318c855a361a1eccd880f33e88c460eb63b4 •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: i40e: Do not use WQ_MEM_RECLAIM flag for workqueue Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in check_flush_dependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the i40iw one is not. Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too.... • https://git.kernel.org/stable/c/4d5957cbdecdbb77d24c1465caadd801c07afa4a •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: smb3: missing lock when picking channel Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index. Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)") En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb3: falta el bloqueo al seleccionar el canal. Coverity detectó un lugar donde deberíamos haber mantenido el bloqueo del canal al acceder al índice del canal ... • https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729 •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: smb3: fix lock ordering potential deadlock in cifs_sync_mid_result Coverity spotted that the cifs_sync_mid_result function could deadlock "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock" Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)") En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb3: corrige el posible i... • https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66 •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that. More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the... • https://git.kernel.org/stable/c/4a200c3b9a40242652b5734630bdd0bcf3aca75f • CWE-400: Uncontrolled Resource Consumption CWE-667: Improper Locking •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Use access_width over bit_width for system memory accesses To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009... • https://git.kernel.org/stable/c/4949affd5288b867cdf115f5b08d6166b2027f87 •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 byt... • https://git.kernel.org/stable/c/a19d3d85e1b854e4a483a55d740a42458085560d • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix memory leak in hci_req_sync_complete() In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: corrija la pérdida de memoria en hci_req_sync_complete() En 'hci_req_sync_complete()', libere siempre el estado de solicitud de sincronización anterior antes de asignar una referencia a una nueva. In ... • https://git.kernel.org/stable/c/f60cb30579d3401cab1ed36b42df5c0568ae0ba7 • CWE-401: Missing Release of Memory after Effective Lifetime •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it still means hlist_for_each_entry_rcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane. In particular, the reference count can be zero. This can happen if ipv6_del_addr is called in par... • https://git.kernel.org/stable/c/5c578aedcb21d79eeb4e9cf04ca5b276ac82614c • CWE-770: Allocation of Resources Without Limits or Throttling •

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

20 May 2024 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr f... • https://git.kernel.org/stable/c/b96e9c671b05f95126753a22145d4509d45ca197 •