Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()<br /> <br /> If we need to increase the tree depth, allocate a new node, and then<br /> race with another thread that increased the tree depth before us, we&amp;#39;ll<br /> still have a preallocated node that might be used later.<br /> <br /> If we then use that node for a new non-root node, it&amp;#39;ll still have a<br /> pointer to the old root instead of being zeroed - fix this by zeroing it<br /> in the cmpxchg failure path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix state management in error path of log writing function<br /> <br /> After commit a694291a6211 ("nilfs2: separate wait function from<br /> nilfs_segctor_write") was applied, the log writing function<br /> nilfs_segctor_do_construct() was able to issue I/O requests continuously<br /> even if user data blocks were split into multiple logs across segments,<br /> but two potential flaws were introduced in its error handling.<br /> <br /> First, if nilfs_segctor_begin_construction() fails while creating the<br /> second or subsequent logs, the log writing function returns without<br /> calling nilfs_segctor_abort_construction(), so the writeback flag set on<br /> pages/folios will remain uncleared. This causes page cache operations to<br /> hang waiting for the writeback flag. For example,<br /> truncate_inode_pages_final(), which is called via nilfs_evict_inode() when<br /> an inode is evicted from memory, will hang.<br /> <br /> Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. <br /> As a result, if the next log write involves checkpoint creation, that&amp;#39;s<br /> fine, but if a partial log write is performed that does not, inodes with<br /> NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files"<br /> list, and their data and b-tree blocks may not be written to the device,<br /> corrupting the block mapping.<br /> <br /> Fix these issues by uniformly calling nilfs_segctor_abort_construction()<br /> on failure of each step in the loop in nilfs_segctor_do_construct(),<br /> having it clean up logs and segment usages according to progress, and<br /> correcting the conditions for calling nilfs_redirty_inodes() to ensure<br /> that the NILFS_I_COLLECTED flag is cleared.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: add bounds checking to ocfs2_xattr_find_entry()<br /> <br /> Add a paranoia check to make sure it doesn&amp;#39;t stray beyond valid memory<br /> region containing ocfs2 xattr entries when scanning for a match. It will<br /> prevent out-of-bound access in case of crafted images.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: usbtmc: prevent kernel-usb-infoleak<br /> <br /> The syzbot reported a kernel-usb-infoleak in usbtmc_write,<br /> we need to clear the structure before filling fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: pause TCM when the firmware is stopped<br /> <br /> Not doing so will make us send a host command to the transport while the<br /> firmware is not alive, which will trigger a WARNING.<br /> <br /> bad state = 0<br /> WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]<br /> RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]<br /> Call Trace:<br /> <br /> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]<br /> iwl_mvm_config_scan+0x198/0x260 [iwlmvm]<br /> iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]<br /> iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]<br /> process_one_work+0x29e/0x640<br /> worker_thread+0x2df/0x690<br /> ? rescuer_thread+0x540/0x540<br /> kthread+0x192/0x1e0<br /> ? set_kthread_struct+0x90/0x90<br /> ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: pm80xx: Set phy-&gt;enable_completion only when we wait for it<br /> <br /> pm8001_phy_control() populates the enable_completion pointer with a stack<br /> address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and<br /> returns. The problem arises when a phy control response comes late. After<br /> 300 ms the pm8001_phy_control() function returns and the passed<br /> enable_completion stack address is no longer valid. Late phy control<br /> response invokes complete() on a dangling enable_completion pointer which<br /> leads to a kernel crash.

Adobe Framemaker versions 2020.6, 2022.4 and earlier are affected by an Untrusted Search Path vulnerability that could lead to arbitrary code execution. An attacker could exploit this vulnerability by inserting a malicious path into the search directories, which the application could unknowingly execute. This could allow the attacker to execute arbitrary code in the context of the current user. Exploitation of this issue requires user interaction.

Adobe Framemaker versions 2020.6, 2022.4 and earlier are affected by an Unrestricted Upload of File with Dangerous Type vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by uploading a malicious file which can be automatically processed or executed by the system. Exploitation of this issue requires user interaction.

Adobe Framemaker versions 2020.6, 2022.4 and earlier are affected by an Integer Overflow or Wraparound vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Adobe Framemaker versions 2020.6, 2022.4 and earlier are affected by an Integer Underflow (Wrap or Wraparound) vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

InCopy versions 19.4, 18.5.3 and earlier are affected by an Unrestricted Upload of File with Dangerous Type vulnerability that could result in arbitrary code execution by an attacker. An attacker could exploit this vulnerability by uploading a malicious file which can then be executed on the server. Exploitation of this issue requires user interaction.

InDesign Desktop versions 19.4, 18.5.3 and earlier are affected by an Unrestricted Upload of File with Dangerous Type vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by uploading a malicious file which, when executed, could run arbitrary code in the context of the server. Exploitation of this issue requires user interaction.