Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-direct: Leak pages on dma_set_decrypted() failure<br /> <br /> On TDX it is possible for the untrusted host to cause<br /> set_memory_encrypted() or set_memory_decrypted() to fail such that an<br /> error is returned and the resulting memory is shared. Callers need to<br /> take care to handle these errors to avoid returning decrypted (shared)<br /> memory to the page allocator, which could lead to functional or security<br /> issues.<br /> <br /> DMA could free decrypted/shared pages if dma_set_decrypted() fails. This<br /> should be a rare case. Just leak the pages in this case instead of<br /> freeing them.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain<br /> <br /> According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of<br /> hdmi rx verification IP that should not enable for HDMI TX.<br /> But actually if the clock is disabled before HDMI/LCDIF probe,<br /> LCDIF will not get pixel clock from HDMI PHY and print the error<br /> logs:<br /> <br /> [CRTC:39:crtc-2] vblank wait timed out<br /> WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260<br /> <br /> Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: check A-MSDU format more carefully<br /> <br /> If it looks like there&amp;#39;s another subframe in the A-MSDU<br /> but the header isn&amp;#39;t fully there, we can end up reading<br /> data out of bounds, only to discard later. Make this a<br /> bit more careful and check if the subframe header can<br /> even be present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: ti: Add a null pointer check to the omap_prm_domain_init<br /> <br /> devm_kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()<br /> <br /> The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an<br /> unsuccessful status. In such cases, the elsiocb is not issued, the<br /> completion is not called, and thus the elsiocb resource is leaked.<br /> <br /> Check return value after calling lpfc_sli4_resume_rpi() and conditionally<br /> release the elsiocb resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btintel: Fix null ptr deref in btintel_read_version<br /> <br /> If hci_cmd_sync_complete() is triggered and skb is NULL, then<br /> hdev-&gt;req_skb is NULL, which will cause this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()<br /> <br /> Many syzbot reports show extreme rtnl pressure, and many of them hint<br /> that smc acquires rtnl in netns creation for no good reason [1]<br /> <br /> This patch returns early from smc_pnet_net_init()<br /> if there is no netdevice yet.<br /> <br /> I am not even sure why smc_pnet_create_pnetids_list() even exists,<br /> because smc_pnet_netdev_event() is also calling<br /> smc_pnet_add_base_pnetid() when handling NETDEV_UP event.<br /> <br /> [1] extract of typical syzbot reports<br /> <br /> 2 locks held by syz-executor.3/12252:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.4/12253:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.1/12257:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.2/12261:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.0/12265:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.3/12268:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.4/12271:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.1/12274:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.2/12280:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: send: handle path ref underflow in header iterate_inode_ref()<br /> <br /> Change BUG_ON to proper error handling if building the path buffer<br /> fails. The pointers are not printed so we don&amp;#39;t accidentally leak kernel<br /> addresses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()<br /> <br /> The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,<br /> as it could be caused only by two impossible conditions:<br /> <br /> - at first the search key is set up to look for a chunk tree item, with<br /> offset -1, this is an inexact search and the key-&gt;offset will contain<br /> the correct offset upon a successful search, a valid chunk tree item<br /> cannot have an offset -1<br /> <br /> - after first successful search, the found_key corresponds to a chunk<br /> item, the offset is decremented by 1 before the next loop, it&amp;#39;s<br /> impossible to find a chunk item there due to alignment and size<br /> constraints

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/zone: Add a null pointer check to the psz_kmsg_read<br /> <br /> kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.