CVE-2024-46719 – usb: typec: ucsi: Fix null pointer dereference in trace
https://notcve.org/view.php?id=CVE-2024-46719
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix null pointer dereference in trace ucsi_register_altmode checks IS_ERR for the alt pointer and treats NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled, ucsi_register_displayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typec_port_register_altmode to register DisplayPort alternate mode as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled. • https://git.kernel.org/stable/c/8095bf0579ed4906a33f7bec675bfb29b6b16a3b https://git.kernel.org/stable/c/7e64cabe81c303bdf6fd26b6a09a3289b33bc870 https://git.kernel.org/stable/c/3aa56313b0de06ce1911950b2cc0c269614a87a9 https://git.kernel.org/stable/c/b4243c05d7e3db0bdbf9124e6fa59b4ca7c807ae https://git.kernel.org/stable/c/3b9f2d9301ae67070fe77a0c06758722fd7172b7 https://git.kernel.org/stable/c/99331fe68a8eaa4097143a33fb0c12d5e5e8e830 https://git.kernel.org/stable/c/99516f76db48e1a9d54cdfed63c1babcee4e71a5 •
CVE-2024-46718 – drm/xe: Don't overmap identity VRAM mapping
https://notcve.org/view.php?id=CVE-2024-46718
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don't overmap identity VRAM mapping Overmapping the identity VRAM mapping is triggering hardware bugs on certain platforms. Use 2M pages for the last unaligned (to 1G) VRAM chunk. v2: - Always use 2M pages for last chunk (Fei Yang) - break loop when 2M pages are used - Add assert for usable_size being 2M aligned v3: - Fix checkpatch • https://git.kernel.org/stable/c/bb706e92c87beb9f2543faa1705ccc330b9e7c65 https://git.kernel.org/stable/c/6d3581edffea0b3a64b0d3094d3f09222e0024f7 •
CVE-2024-46717 – net/mlx5e: SHAMPO, Fix incorrect page release
https://notcve.org/view.php?id=CVE-2024-46717
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix incorrect page release Under the following conditions: 1) No skb created yet 2) header_size == 0 (no SHAMPO header) 3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the last page fragment of a SHAMPO header page) a new skb is formed with a page that is NOT a SHAMPO header page (it is a regular data page). Further down in the same function (mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from header_index is released. This is wrong and it leads to SHAMPO header pages being released more than once. • https://git.kernel.org/stable/c/03924d117625ecb10ee3c9b65930bcb2c37ae629 https://git.kernel.org/stable/c/ae9018e3f61ba5cc1f08a6e51d3c0bef0a79f3ab https://git.kernel.org/stable/c/c909ab41df2b09cde919801c7a7b6bb2cc37ea22 https://git.kernel.org/stable/c/70bd03b89f20b9bbe51a7f73c4950565a17a45f7 •
CVE-2024-46716 – dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor
https://notcve.org/view.php?id=CVE-2024-46716
In the Linux kernel, the following vulnerability has been resolved: dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor Remove list_del call in msgdma_chan_desc_cleanup, this should be the role of msgdma_free_descriptor. In consequence replace list_add_tail with list_move_tail in msgdma_free_descriptor. This fixes the path: msgdma_free_chan_resources -> msgdma_free_descriptors -> msgdma_free_desc_list -> msgdma_free_descriptor which does not correctly free the descriptors as first nodes were not removed from the list. • https://git.kernel.org/stable/c/a3480e59fdbe5585d2d1eff0bed7671583acf725 https://git.kernel.org/stable/c/20bf2920a869f9dbda0ef8c94c87d1901a64a716 https://git.kernel.org/stable/c/db67686676c7becc1910bf1d6d51505876821863 https://git.kernel.org/stable/c/54e4ada1a4206f878e345ae01cf37347d803d1b1 •
CVE-2024-46715 – driver: iio: add missing checks on iio_info's callback access
https://notcve.org/view.php?id=CVE-2024-46715
In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]--- • https://git.kernel.org/stable/c/0cc7e0ee31e5c44904e98e2229d591e093282a70 https://git.kernel.org/stable/c/72f022ebb9deac28663fa4c04ba315ed5d6654d1 https://git.kernel.org/stable/c/dc537a72f64890d883d24ae4ac58733fc5bc523d https://git.kernel.org/stable/c/c4ec8dedca961db056ec85cb7ca8c9f7e2e92252 •