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 /> thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()<br /> <br /> The memory allocated in tb_queue_dp_bandwidth_request() needs to be<br /> released once the request is handled to avoid leaking it.

*** 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 /> wifi: rtw88: Fix memory leak in rtw88_usb<br /> <br /> Kmemleak shows the following leak arising from routine in the usb<br /> probe routine:<br /> <br /> unreferenced object 0xffff895cb29bba00 (size 512):<br /> comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s)<br /> hex dump (first 32 bytes):<br /> 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0...<br /> 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U......<br /> backtrace:<br /> [] kmalloc_trace+0x26/0x90<br /> [] rtw_usb_probe+0x2f1/0x680 [rtw_usb]<br /> [] usb_probe_interface+0xdd/0x2e0 [usbcore]<br /> [] really_probe+0x18e/0x3d0<br /> [] __driver_probe_device+0x78/0x160<br /> [] driver_probe_device+0x1f/0x90<br /> [] __driver_attach+0xbf/0x1b0<br /> [] bus_for_each_dev+0x70/0xc0<br /> [] bus_add_driver+0x10e/0x210<br /> [] driver_register+0x55/0xf0<br /> [] usb_register_driver+0x88/0x140 [usbcore]<br /> [] do_one_initcall+0x43/0x210<br /> [] do_init_module+0x4a/0x200<br /> [] __do_sys_finit_module+0xac/0x120<br /> [] do_syscall_64+0x56/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The leak was verified to be real by unloading the driver, which resulted<br /> in a dangling pointer to the allocation.<br /> <br /> The allocated memory is freed in rtw_usb_intf_deinit().

*** 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 /> null_blk: fix poll request timeout handling<br /> <br /> When doing io_uring benchmark on /dev/nullb0, it&amp;#39;s easy to crash the<br /> kernel if poll requests timeout triggered, as reported by David. [1]<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> Workqueue: kblockd blk_mq_timeout_work<br /> RIP: 0010:null_timeout_rq+0x4e/0x91<br /> Call Trace:<br /> ? null_timeout_rq+0x4e/0x91<br /> blk_mq_handle_expired+0x31/0x4b<br /> bt_iter+0x68/0x84<br /> ? bt_tags_iter+0x81/0x81<br /> __sbitmap_for_each_set.constprop.0+0xb0/0xf2<br /> ? __blk_mq_complete_request_remote+0xf/0xf<br /> bt_for_each+0x46/0x64<br /> ? __blk_mq_complete_request_remote+0xf/0xf<br /> ? percpu_ref_get_many+0xc/0x2a<br /> blk_mq_queue_tag_busy_iter+0x14d/0x18e<br /> blk_mq_timeout_work+0x95/0x127<br /> process_one_work+0x185/0x263<br /> worker_thread+0x1b5/0x227<br /> <br /> This is indeed a race problem between null_timeout_rq() and null_poll().<br /> <br /> null_poll() null_timeout_rq()<br /> spin_lock(&amp;nq-&gt;poll_lock)<br /> list_splice_init(&amp;nq-&gt;poll_list, &amp;list)<br /> spin_unlock(&amp;nq-&gt;poll_lock)<br /> <br /> while (!list_empty(&amp;list))<br /> req = list_first_entry()<br /> list_del_init()<br /> ...<br /> blk_mq_add_to_batch()<br /> // req-&gt;rq_next = NULL<br /> spin_lock(&amp;nq-&gt;poll_lock)<br /> <br /> // rq-&gt;queuelist-&gt;next == NULL<br /> list_del_init(&amp;rq-&gt;queuelist)<br /> <br /> spin_unlock(&amp;nq-&gt;poll_lock)<br /> <br /> Fix these problems by setting requests state to MQ_RQ_COMPLETE under<br /> nq-&gt;poll_lock protection, in which null_timeout_rq() can safely detect<br /> this race and early return.<br /> <br /> Note this patch just fix the kernel panic when request timeout happen.<br /> <br /> [1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/

*** 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 /> 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: 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 /> 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().