Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: check &amp;#39;jh-&gt;b_transaction&amp;#39; before removing it from checkpoint<br /> <br /> Following process will corrupt ext4 image:<br /> Step 1:<br /> jbd2_journal_commit_transaction<br /> __jbd2_journal_insert_checkpoint(jh, commit_transaction)<br /> // Put jh into trans1-&gt;t_checkpoint_list<br /> journal-&gt;j_checkpoint_transactions = commit_transaction<br /> // Put trans1 into journal-&gt;j_checkpoint_transactions<br /> <br /> Step 2:<br /> do_get_write_access<br /> test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty<br /> __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2<br /> <br /> Step 3:<br /> drop_cache<br /> journal_shrink_one_cp_list<br /> jbd2_journal_try_remove_checkpoint<br /> if (!trylock_buffer(bh)) // lock bh, true<br /> if (buffer_dirty(bh)) // buffer is not dirty<br /> __jbd2_journal_remove_checkpoint(jh)<br /> // remove jh from trans1-&gt;t_checkpoint_list<br /> <br /> Step 4:<br /> jbd2_log_do_checkpoint<br /> trans1 = journal-&gt;j_checkpoint_transactions<br /> // jh is not in trans1-&gt;t_checkpoint_list<br /> jbd2_cleanup_journal_tail(journal) // trans1 is done<br /> <br /> Step 5: Power cut, trans2 is not committed, jh is lost in next mounting.<br /> <br /> Fix it by checking &amp;#39;jh-&gt;b_transaction&amp;#39; before remove it from checkpoint.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix unsafe drain work queue code<br /> <br /> If create_qp does not fully succeed it is possible for qp cleanup<br /> code to attempt to drain the send or recv work queues before the<br /> queues have been created causing a seg fault. This patch checks<br /> to see if the queues exist before attempting to drain them.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()<br /> <br /> The following call trace was observed:<br /> <br /> localhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete<br /> localhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092<br /> localhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291"<br /> localhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]<br /> localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G B W OE --------- --- 5.14.0-70.22.1.el9_0.x86_64+debug #1<br /> localhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022<br /> localhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]<br /> localhost kernel: Call Trace:<br /> localhost kernel: dump_stack_lvl+0x57/0x7d<br /> localhost kernel: check_preemption_disabled+0xc8/0xd0<br /> localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]<br /> <br /> Use raw_smp_processor_id() instead of smp_processor_id().<br /> <br /> Also use queue_work() across the driver instead of queue_work_on() thus<br /> avoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix deinitialization of firmware resources<br /> <br /> Currently, in ath11k_ahb_fw_resources_init(), iommu domain<br /> mapping is done only for the chipsets having fixed firmware<br /> memory. Also, for such chipsets, mapping is done only if it<br /> does not have TrustZone support.<br /> <br /> During deinitialization, only if TrustZone support is not there,<br /> iommu is unmapped back. However, for non fixed firmware memory<br /> chipsets, TrustZone support is not there and this makes the<br /> condition check to true and it tries to unmap the memory which<br /> was not mapped during initialization.<br /> <br /> This leads to the following trace -<br /> <br /> [ 83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> [ 83.259537] Modules linked in: ath11k_ahb ath11k qmi_helpers<br /> .. snip ..<br /> [ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 83.287228] pc : __iommu_unmap+0x30/0x140<br /> [ 83.293907] lr : iommu_unmap+0x5c/0xa4<br /> [ 83.298072] sp : ffff80000b3abad0<br /> .. snip ..<br /> [ 83.369175] Call trace:<br /> [ 83.376282] __iommu_unmap+0x30/0x140<br /> [ 83.378541] iommu_unmap+0x5c/0xa4<br /> [ 83.382360] ath11k_ahb_fw_resource_deinit.part.12+0x2c/0xac [ath11k_ahb]<br /> [ 83.385666] ath11k_ahb_free_resources+0x140/0x17c [ath11k_ahb]<br /> [ 83.392521] ath11k_ahb_shutdown+0x34/0x40 [ath11k_ahb]<br /> [ 83.398248] platform_shutdown+0x20/0x2c<br /> [ 83.403455] device_shutdown+0x16c/0x1c4<br /> [ 83.407621] kernel_restart_prepare+0x34/0x3c<br /> [ 83.411529] kernel_restart+0x14/0x74<br /> [ 83.415781] __do_sys_reboot+0x1c4/0x22c<br /> [ 83.419427] __arm64_sys_reboot+0x1c/0x24<br /> [ 83.423420] invoke_syscall+0x44/0xfc<br /> [ 83.427326] el0_svc_common.constprop.3+0xac/0xe8<br /> [ 83.430974] do_el0_svc+0xa0/0xa8<br /> [ 83.435659] el0_svc+0x1c/0x44<br /> [ 83.438957] el0t_64_sync_handler+0x60/0x144<br /> [ 83.441910] el0t_64_sync+0x15c/0x160<br /> [ 83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0)<br /> [ 83.449903] ---[ end trace 0000000000000000 ]---<br /> <br /> This can be reproduced by probing an AHB chipset which is not<br /> having a fixed memory region. During reboot (or rmmod) trace<br /> can be seen.<br /> <br /> Fix this issue by adding a condition check on firmware fixed memory<br /> hw_param as done in the counter initialization function.<br /> <br /> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: Fix leak in devfreq_dev_release()<br /> <br /> srcu_init_notifier_head() allocates resources that need to be released<br /> with a srcu_cleanup_notifier_head() call.<br /> <br /> Reported by kmemleak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf<br /> <br /> An integer overflow occurs in the iwl_write_to_user_buf() function,<br /> which is called by the iwl_dbgfs_monitor_data_read() function.<br /> <br /> static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,<br /> void *buf, ssize_t *size,<br /> ssize_t *bytes_copied)<br /> {<br /> int buf_size_left = count - *bytes_copied;<br /> <br /> buf_size_left = buf_size_left - (buf_size_left % sizeof(u32));<br /> if (*size &gt; buf_size_left)<br /> *size = buf_size_left;<br /> <br /> If the user passes a SIZE_MAX value to the "ssize_t count" parameter,<br /> the ssize_t count parameter is assigned to "int buf_size_left".<br /> Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a<br /> negative number, so "*size" is assigned "buf_size_left" and goes into<br /> the third argument of the copy_to_user function, causing a heap overflow.<br /> <br /> This is not a security vulnerability because iwl_dbgfs_monitor_data_read()<br /> is a debugfs operation with 0400 privileges.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: fix time stamp counter initialization<br /> <br /> If the gs_usb device driver is unloaded (or unbound) before the<br /> interface is shut down, the USB stack first calls the struct<br /> usb_driver::disconnect and then the struct net_device_ops::ndo_stop<br /> callback.<br /> <br /> In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more<br /> RX&amp;#39;ed CAN frames are send from the USB device to the host. Later in<br /> gs_can_close() a reset control message is send to each CAN channel to<br /> remove the controller from the CAN bus. In this race window the USB<br /> device can still receive CAN frames from the bus and internally queue<br /> them to be send to the host.<br /> <br /> At least in the current version of the candlelight firmware, the queue<br /> of received CAN frames is not emptied during the reset command. After<br /> loading (or binding) the gs_usb driver, new URBs are submitted during<br /> the struct net_device_ops::ndo_open callback and the candlelight<br /> firmware starts sending its already queued CAN frames to the host.<br /> <br /> However, this scenario was not considered when implementing the<br /> hardware timestamp function. The cycle counter/time counter<br /> infrastructure is set up (gs_usb_timestamp_init()) after the USBs are<br /> submitted, resulting in a NULL pointer dereference if<br /> timecounter_cyc2time() (via the call chain:<br /> gs_usb_receive_bulk_callback() -&gt; gs_usb_set_timestamp() -&gt;<br /> gs_usb_skb_set_timestamp()) is called too early.<br /> <br /> Move the gs_usb_timestamp_init() function before the URBs are<br /> submitted to fix this problem.<br /> <br /> For a comprehensive solution, we need to consider gs_usb devices with<br /> more than 1 channel. The cycle counter/time counter infrastructure is<br /> setup per channel, but the RX URBs are per device. Once gs_can_open()<br /> of _a_ channel has been called, and URBs have been submitted, the<br /> gs_usb_receive_bulk_callback() can be called for _all_ available<br /> channels, even for channels that are not running, yet. As cycle<br /> counter/time counter has not set up, this will again lead to a NULL<br /> pointer dereference.<br /> <br /> Convert the cycle counter/time counter from a "per channel" to a "per<br /> device" functionality. Also set it up, before submitting any URBs to<br /> the device.<br /> <br /> Further in gs_usb_receive_bulk_callback(), don&amp;#39;t process any URBs for<br /> not started CAN channels, only resubmit the URB.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup,freezer: hold cpu_hotplug_lock before freezer_mutex<br /> <br /> syzbot is reporting circular locking dependency between cpu_hotplug_lock<br /> and freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core<br /> freezer logic") replaced atomic_inc() in freezer_apply_state() with<br /> static_branch_inc() which holds cpu_hotplug_lock.<br /> <br /> cpu_hotplug_lock =&gt; cgroup_threadgroup_rwsem =&gt; freezer_mutex<br /> <br /> cgroup_file_write() {<br /> cgroup_procs_write() {<br /> __cgroup_procs_write() {<br /> cgroup_procs_write_start() {<br /> cgroup_attach_lock() {<br /> cpus_read_lock() {<br /> percpu_down_read(&amp;cpu_hotplug_lock);<br /> }<br /> percpu_down_write(&amp;cgroup_threadgroup_rwsem);<br /> }<br /> }<br /> cgroup_attach_task() {<br /> cgroup_migrate() {<br /> cgroup_migrate_execute() {<br /> freezer_attach() {<br /> mutex_lock(&amp;freezer_mutex);<br /> (...snipped...)<br /> }<br /> }<br /> }<br /> }<br /> (...snipped...)<br /> }<br /> }<br /> }<br /> <br /> freezer_mutex =&gt; cpu_hotplug_lock<br /> <br /> cgroup_file_write() {<br /> freezer_write() {<br /> freezer_change_state() {<br /> mutex_lock(&amp;freezer_mutex);<br /> freezer_apply_state() {<br /> static_branch_inc(&amp;freezer_active) {<br /> static_key_slow_inc() {<br /> cpus_read_lock();<br /> static_key_slow_inc_cpuslocked();<br /> cpus_read_unlock();<br /> }<br /> }<br /> }<br /> mutex_unlock(&amp;freezer_mutex);<br /> }<br /> }<br /> }<br /> <br /> Swap locking order by moving cpus_read_lock() in freezer_apply_state()<br /> to before mutex_lock(&amp;freezer_mutex) in freezer_change_state().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()<br /> <br /> A fix for:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]<br /> Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013<br /> <br /> When edev-&gt;components is zero, accessing edev-&gt;component[0] members is<br /> wrong.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l2-mem2mem: add lock to protect parameter num_rdy<br /> <br /> Getting below error when using KCSAN to check the driver. Adding lock to<br /> protect parameter num_rdy when getting the value with function:<br /> v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready.<br /> <br /> kworker/u16:3: [name:report&amp;]BUG: KCSAN: data-race in v4l2_m2m_buf_queue<br /> kworker/u16:3: [name:report&amp;]<br /> <br /> kworker/u16:3: [name:report&amp;]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7:<br /> kworker/u16:3:  v4l2_m2m_buf_queue+0xd8/0x10c

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix hci_suspend_sync crash<br /> <br /> If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier<br /> may still be accessing it, it can cause the program to crash.<br /> Here&amp;#39;s the call trace:<br /> [102152.653246] Call Trace:<br /> [102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]<br /> [102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]<br /> [102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]<br /> [102152.653268] notifier_call_chain+0x43/0x6b<br /> [102152.653271] __blocking_notifier_call_chain+0x48/0x69<br /> [102152.653273] __pm_notifier_call_chain+0x22/0x39<br /> [102152.653276] pm_suspend+0x287/0x57c<br /> [102152.653278] state_store+0xae/0xe5<br /> [102152.653281] kernfs_fop_write+0x109/0x173<br /> [102152.653284] __vfs_write+0x16f/0x1a2<br /> [102152.653287] ? selinux_file_permission+0xca/0x16f<br /> [102152.653289] ? security_file_permission+0x36/0x109<br /> [102152.653291] vfs_write+0x114/0x21d<br /> [102152.653293] __x64_sys_write+0x7b/0xdb<br /> [102152.653296] do_syscall_64+0x59/0x194<br /> [102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1<br /> <br /> This patch holds the reference count of the hci_dev object while<br /> processing it in hci_suspend_notifier to avoid potential crash<br /> caused by the race condition.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix a memory leak<br /> <br /> Add a forgotten kfree().