Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()<br /> <br /> A race condition exists in the NFC LLCP connection state machine where<br /> the connection acceptance packet (CC) can be processed concurrently with<br /> socket release. This can lead to a use-after-free of the socket object.<br /> <br /> When nfc_llcp_recv_cc() moves the socket from the connecting_sockets<br /> list to the sockets list, it does so without holding the socket lock.<br /> If llcp_sock_release() is executing concurrently, it might have already<br /> unlinked the socket and dropped its references, which can result in<br /> nfc_llcp_recv_cc() linking a freed socket into the live list.<br /> <br /> Fix this by holding lock_sock() during the state transition and list<br /> movement in nfc_llcp_recv_cc(). After acquiring the lock, check if<br /> the socket is still hashed to ensure it hasn&amp;#39;t already been unlinked<br /> and marked for destruction by the release path. This aligns the locking<br /> pattern with recv_hdlc() and recv_disc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: llcp: Fix use-after-free in llcp_sock_release()<br /> <br /> llcp_sock_release() unconditionally unlinks the socket from the local<br /> sockets list. However, if the socket is still in connecting state, it<br /> is on the connecting list.<br /> <br /> Fix this by checking the socket state and unlinking from the correct list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: cmis: validate start_cmd_payload_size from module<br /> <br /> The CMIS firmware update code reads start_cmd_payload_size from<br /> the module&amp;#39;s FW Management Features CDB reply and uses it directly<br /> as the byte count for memcpy. The destination buffer is 112 bytes<br /> (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8). So a malicious<br /> module (or corrupted response) can cause a OOB write later on in<br /> cmis_fw_update_start_download().<br /> <br /> Let&amp;#39;s error out. If modules that expect longer LPL writes actually<br /> exist we should revisit.<br /> <br /> struct cmis_cdb_start_fw_download_pl&amp;#39;s definition has to move,<br /> no change there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: cmis: require exact CDB reply length<br /> <br /> Malicious SFP module could respond with rpl_len longer than<br /> what cmis_cdb_process_reply() expected, leading to OOB writes.<br /> Malicious HW is a bit theoretical but some modules may just<br /> be buggy and/or the reads may occasionally get corrupted,<br /> so let&amp;#39;s protect the kernel.<br /> <br /> The existing check protects from short replies. We need to<br /> protect from long ones, too. All callers that pass a non-zero<br /> rpl_exp_len cast the reply payload to a fixed-layout struct<br /> and read fields at fixed offsets, with no version negotiation<br /> or short-reply handling:<br /> <br /> - cmis_cdb_validate_password()<br /> - cmis_cdb_module_features_get()<br /> - cmis_fw_update_fw_mng_features_get()<br /> <br /> so let&amp;#39;s assume that responses longer than expected do not<br /> have to be handled gracefully here. Add a warning message<br /> to make the debug easier in case my understanding is wrong...<br /> <br /> Note that page_data-&gt;length (argument of kmalloc) comes from<br /> last arg to ethtool_cmis_page_init() which is rpl_exp_len.<br /> <br /> Note2 that AIs also like to point out overflows in args-&gt;req.payload<br /> itself (which is a fixed-size 120 B buffer, on the stack),<br /> but callers should be reading structs defined by the standard,<br /> so protecting from requests for more data than max seem like<br /> defensive programming.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: module: avoid leaking a netdev ref on module flash errors<br /> <br /> module_flash_fw_schedule() is missing undo for setting<br /> the "in_progress" flag and taking the netdev reference.<br /> Delay taking these, the device can&amp;#39;t disappear while<br /> we are holding rtnl_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: module: call ethnl_ops_complete() on module flash errors<br /> <br /> When validate() fails we are skipping over ethnl_ops_complete()<br /> even tho we already called ethnl_ops_begin().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: rss: fix indir_table and hkey leak on get_rxfh failure<br /> <br /> rss_prepare_get() allocates the indirection table and hash key buffer<br /> via rss_get_data_alloc(), then calls ops-&gt;get_rxfh() to populate them.<br /> If get_rxfh() fails, the function returns an error without freeing<br /> the allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: fix potential OOB access in supervision frame handling<br /> <br /> Ensure the entire TLV header is linearized before access by adding<br /> sizeof(struct hsr_sup_tlv) to the pskb_may_pull() calls. Without this,<br /> a truncated frame could cause an out-of-bounds access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: oss: Fix setup list UAF on proc write error<br /> <br /> snd_pcm_oss_proc_write() links a newly allocated setup entry into the<br /> OSS setup list before duplicating the task name. If the task-name<br /> allocation fails, the error path frees the already linked entry and<br /> leaves setup_list pointing at freed memory.<br /> <br /> A later OSS device open can then walk the stale list entry in<br /> snd_pcm_oss_look_for_setup() and dereference freed memory.<br /> <br /> Allocate the task name and initialize the setup entry before publishing<br /> the entry on setup_list. Also fetch the initial proc read iterator only<br /> after taking setup_mutex, so all setup_list traversal follows the same<br /> list lifetime rules.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: free net-&gt;ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table()<br /> <br /> ipv4_sysctl_exit_net() is currently freeing net-&gt;ipv4.sysctl_local_reserved_ports<br /> too soon.<br /> <br /> Only after unregister_net_sysctl_table() we can be sure no threads can possibly<br /> use the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Run queues for all non-SDEV_DEL devices from scsi_run_host_queues<br /> <br /> While a SCSI host is in a recovery state, scsi_mq_requeue_cmd() will not<br /> set the requeue list for a requeued command to be kicked in the future.<br /> The expectation is a call to scsi_run_host_queues() will kick all SCSI<br /> devices once the recovery state is cleared.<br /> <br /> However, scsi_run_host_queues() uses shost_for_each_device() which uses<br /> scsi_device_get() and so will ignore devices in a partially removed<br /> state like SDEV_CANCEL. But these devices may also have requeued<br /> requests, leaving their requests stuck from not being kicked and causing<br /> the removal process of the device to hang.<br /> <br /> scsi_run_host_queues() needs to run against more devices than the macro<br /> shost_for_each_device() allows. Instead of using the too limiting<br /> scsi_device_get() state checks, only ignore devices in SDEV_DEL state or<br /> when unable to acquire a reference. Attempt to run the queues for all<br /> other devices when scsi_run_host_queues() is called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()<br /> <br /> In some cases, iptunnel_pmtud_check_icmp() can be called while<br /> skb transport header is not set.<br /> <br /> This triggers an out-of-bound access, because<br /> (typeof(skb-&gt;transport_header))~0U is 65535.<br /> <br /> Access the icmp header based on IPv4 network header,<br /> after making sure icmp-&gt;type is present in skb linear part.<br /> <br /> Note that iptunnel_pmtud_check_icmpv6()) is fine.