Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file()<br /> <br /> If overlay is used on top of btrfs, dentry-&gt;d_sb translates to overlay&amp;#39;s<br /> super block and fsid assignment will lead to a crash.<br /> <br /> Use file_inode(file)-&gt;i_sb to always get btrfs_sb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> srcu: Use irq_work to start GP in tiny SRCU<br /> <br /> Tiny SRCU&amp;#39;s srcu_gp_start_if_needed() directly calls schedule_work(),<br /> which acquires the workqueue pool-&gt;lock.<br /> <br /> This causes a lockdep splat when call_srcu() is called with a scheduler<br /> lock held, due to:<br /> <br /> call_srcu() [holding pi_lock]<br /> srcu_gp_start_if_needed()<br /> schedule_work() -&gt; pool-&gt;lock<br /> <br /> workqueue_init() / create_worker() [holding pool-&gt;lock]<br /> wake_up_process() -&gt; try_to_wake_up() -&gt; pi_lock<br /> <br /> Also add irq_work_sync() to cleanup_srcu_struct() to prevent a<br /> use-after-free if a queued irq_work fires after cleanup begins.<br /> <br /> Tested with rcutorture SRCU-T and no lockdep warnings.<br /> <br /> [ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_work<br /> to start process_srcu()" ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: ensure safe access to master conntrack<br /> <br /> Holding reference on the expectation is not sufficient, the master<br /> conntrack object can just go away, making exp-&gt;master invalid.<br /> <br /> To access exp-&gt;master safely:<br /> <br /> - Grab the nf_conntrack_expect_lock, this gets serialized with<br /> clean_from_lists() which also holds this lock when the master<br /> conntrack goes away.<br /> <br /> - Hold reference on master conntrack via nf_conntrack_find_get().<br /> Not so easy since the master tuple to look up for the master conntrack<br /> is not available in the existing problematic paths.<br /> <br /> This patch goes for extending the nf_conntrack_expect_lock section<br /> to address this issue for simplicity, in the cases that are described<br /> below this is just slightly extending the lock section.<br /> <br /> The add expectation command already holds a reference to the master<br /> conntrack from ctnetlink_create_expect().<br /> <br /> However, the delete expectation command needs to grab the spinlock<br /> before looking up for the expectation. Expand the existing spinlock<br /> section to address this to cover the expectation lookup. Note that,<br /> the nf_ct_expect_iterate_net() calls already grabs the spinlock while<br /> iterating over the expectation table, which is correct.<br /> <br /> The get expectation command needs to grab the spinlock to ensure master<br /> conntrack does not go away. This also expands the existing spinlock<br /> section to cover the expectation lookup too. I needed to move the<br /> netlink skb allocation out of the spinlock to keep it GFP_KERNEL.<br /> <br /> For the expectation events, the IPEXP_DESTROY event is already delivered<br /> under the spinlock, just move the delivery of IPEXP_NEW under the<br /> spinlock too because the master conntrack event cache is reached through<br /> exp-&gt;master.<br /> <br /> While at it, add lockdep notations to help identify what codepaths need<br /> to grab the spinlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix zero size inode with non-zero size after log replay<br /> <br /> When logging that an inode exists, as part of logging a new name or<br /> logging new dir entries for a directory, we always set the generation of<br /> the logged inode item to 0. This is to signal during log replay (in<br /> overwrite_item()), that we should not set the i_size since we only logged<br /> that an inode exists, so the i_size of the inode in the subvolume tree<br /> must be preserved (as when we log new names or that an inode exists, we<br /> don&amp;#39;t log extents).<br /> <br /> This works fine except when we have already logged an inode in full mode<br /> or it&amp;#39;s the first time we are logging an inode created in a past<br /> transaction, that inode has a new i_size of 0 and then we log a new name<br /> for the inode (due to a new hardlink or a rename), in which case we log<br /> an i_size of 0 for the inode and a generation of 0, which causes the log<br /> replay code to not update the inode&amp;#39;s i_size to 0 (in overwrite_item()).<br /> <br /> An example scenario:<br /> <br /> mkdir /mnt/dir<br /> xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo<br /> <br /> sync<br /> <br /> xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo<br /> <br /> ln /mnt/dir/foo /mnt/dir/bar<br /> <br /> xfs_io -c "fsync" /mnt/dir<br /> <br /> <br /> <br /> After log replay the file remains with a size of 64K. This is because when<br /> we first log the inode, when we fsync file foo, we log its current i_size<br /> of 0, and then when we create a hard link we log again the inode in exists<br /> mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we<br /> add to the log tree, so during log replay overwrite_item() sees that the<br /> generation is 0 and i_size is 0 so we skip updating the inode&amp;#39;s i_size<br /> from 64K to 0.<br /> <br /> Fix this by making sure at fill_inode_item() we always log the real<br /> generation of the inode if it was logged in the current transaction with<br /> the i_size we logged before. Also if an inode created in a previous<br /> transaction is logged in exists mode only, make sure we log the i_size<br /> stored in the inode item located from the commit root, so that if we log<br /> multiple times that the inode exists we get the correct i_size.<br /> <br /> A test case for fstests will follow soon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: annotate data-races around hdev-&gt;req_status<br /> <br /> __hci_cmd_sync_sk() sets hdev-&gt;req_status under hdev-&gt;req_lock:<br /> <br /> hdev-&gt;req_status = HCI_REQ_PEND;<br /> <br /> However, several other functions read or write hdev-&gt;req_status without<br /> holding any lock:<br /> <br /> - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)<br /> - hci_cmd_sync_complete() reads/writes from HCI event completion<br /> - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write<br /> - hci_abort_conn() reads in connection abort path<br /> <br /> Since __hci_cmd_sync_sk() runs on hdev-&gt;req_workqueue while<br /> hci_send_cmd_sync() runs on hdev-&gt;workqueue, these are different<br /> workqueues that can execute concurrently on different CPUs. The plain<br /> C accesses constitute a data race.<br /> <br /> Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses<br /> to hdev-&gt;req_status to prevent potential compiler optimizations that<br /> could affect correctness (e.g., load fusing in the wait_event<br /> condition or store reordering).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix double free related to rereg_user_mr<br /> <br /> If IB_MR_REREG_TRANS is set during rereg_user_mr, the<br /> umem will be released and a new one will be allocated<br /> in irdma_rereg_mr_trans. If any step of irdma_rereg_mr_trans<br /> fails after the new umem is allocated, it releases the umem,<br /> but does not set iwmr-&gt;region to NULL. The problem is that<br /> this failure is propagated to the user, who will then call<br /> ibv_dereg_mr (as they should). Then, the dereg_mr path will<br /> see a non-NULL umem and attempt to call ib_umem_release again.<br /> <br /> Fix this by setting iwmr-&gt;region to NULL after ib_umem_release.<br /> <br /> Fixed: 5ac388db27c4 ("RDMA/irdma: Add support to re-register a memory region")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86: shadow stacks: proper error handling for mmap lock<br /> <br /> 김영민 reports that shstk_pop_sigframe() doesn&amp;#39;t check for errors from<br /> mmap_read_lock_killable(), which is a silly oversight, and also shows<br /> that we haven&amp;#39;t marked those functions with "__must_check", which would<br /> have immediately caught it.<br /> <br /> So let&amp;#39;s fix both issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: Fix memory leak of BO array in hang state<br /> <br /> The hang state&amp;#39;s BO array is allocated separately with kzalloc() in<br /> vc4_save_hang_state() but never freed in vc4_free_hang_state(). Add the<br /> missing kfree() for the BO array before freeing the hang state struct.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: validate bsscfg indices in IF events<br /> <br /> brcmf_fweh_handle_if_event() validates the firmware-provided interface<br /> index before it touches drvr-&gt;iflist[], but it still uses the raw<br /> bsscfgidx field as an array index without a matching range check.<br /> <br /> Reject IF events whose bsscfg index does not fit in drvr-&gt;iflist[]<br /> before indexing the interface array.<br /> <br /> [add missing wifi prefix]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: roccat: fix use-after-free in roccat_report_event<br /> <br /> roccat_report_event() iterates over the device-&gt;readers list without<br /> holding the readers_lock. This allows a concurrent roccat_release() to<br /> remove and free a reader while it&amp;#39;s still being accessed, leading to a<br /> use-after-free.<br /> <br /> Protect the readers list traversal with the readers_lock mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath<br /> <br /> When cifs_sanitize_prepath is called with an empty string or a string<br /> containing only delimiters (e.g., "/"), the current logic attempts to<br /> check *(cursor2 - 1) before cursor2 has advanced. This results in an<br /> out-of-bounds read.<br /> <br /> This patch adds an early exit check after stripping prepended<br /> delimiters. If no path content remains, the function returns NULL.<br /> <br /> The bug was identified via manual audit and verified using a<br /> standalone test case compiled with AddressSanitizer, which<br /> triggered a SEGV on affected inputs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: fix incorrect dentry refcount in cachefiles_cull()<br /> <br /> The patch mentioned below changed cachefiles_bury_object() to expect 2<br /> references to the &amp;#39;rep&amp;#39; dentry. Three of the callers were changed to<br /> use start_removing_dentry() which takes an extra reference so in those<br /> cases the call gets the expected references.<br /> <br /> However there is another call to cachefiles_bury_object() in<br /> cachefiles_cull() which did not need to be changed to use<br /> start_removing_dentry() and so was not properly considered.<br /> It still passed the dentry with just one reference so the net result is<br /> that a reference is lost.<br /> <br /> To meet the expectations of cachefiles_bury_object(), cachefiles_cull()<br /> must take an extra reference before the call. It will be dropped by<br /> cachefiles_bury_object().