Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed<br /> <br /> If some items in nsim_dev_resources_register() fail, memory leak will<br /> occur. The following is the memory leak information.<br /> <br /> unreferenced object 0xffff888074c02600 (size 128):<br /> comm "echo", pid 8159, jiffies 4294945184 (age 493.530s)<br /> hex dump (first 32 bytes):<br /> 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G..............<br /> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................<br /> backtrace:<br /> [] kmalloc_trace+0x22/0x60<br /> [] devl_resource_register+0x144/0x4e0<br /> [] nsim_drv_probe+0x37a/0x1260<br /> [] really_probe+0x20b/0xb10<br /> [] __driver_probe_device+0x1b3/0x4a0<br /> [] driver_probe_device+0x49/0x140<br /> [] __device_attach_driver+0x18c/0x2a0<br /> [] bus_for_each_drv+0x151/0x1d0<br /> [] __device_attach+0x1c9/0x4e0<br /> [] bus_probe_device+0x1d5/0x280<br /> [] device_add+0xae0/0x1cb0<br /> [] new_device_store+0x3b6/0x5f0<br /> [] bus_attr_store+0x72/0xa0<br /> [] sysfs_kf_write+0x106/0x160<br /> [] kernfs_fop_write_iter+0x3a8/0x5a0<br /> [] vfs_write+0x8f0/0xc80

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-core: Fix double free in dvb_register_device()<br /> <br /> In function dvb_register_device() -&gt; dvb_register_media_device() -&gt;<br /> dvb_create_media_entity(), dvb-&gt;entity is allocated and initialized. If<br /> the initialization fails, it frees the dvb-&gt;entity, and return an error<br /> code. The caller takes the error code and handles the error by calling<br /> dvb_media_device_free(), which unregisters the entity and frees the<br /> field again if it is not NULL. As dvb-&gt;entity may not NULLed in<br /> dvb_create_media_entity() when the allocation of dvbdev-&gt;pad fails, a<br /> double free may occur. This may also cause an Use After free in<br /> media_device_unregister_entity().<br /> <br /> Fix this by storing NULL to dvb-&gt;entity when it is freed.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache: Fix UAF in destroy()<br /> <br /> Dm_cache also has the same UAF problem when dm_resume()<br /> and dm_destroy() are concurrent.<br /> <br /> Therefore, cancelling timer again in destroy().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: alx: take rtnl_lock on resume<br /> <br /> Zbynek reports that alx trips an rtnl assertion on resume:<br /> <br /> RTNL: assertion failed at net/core/dev.c (2891)<br /> RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0<br /> Call Trace:<br /> <br /> __alx_open+0x230/0x570 [alx]<br /> alx_resume+0x54/0x80 [alx]<br /> ? pci_legacy_resume+0x80/0x80<br /> dpm_run_callback+0x4a/0x150<br /> device_resume+0x8b/0x190<br /> async_resume+0x19/0x30<br /> async_run_entry_fn+0x30/0x130<br /> process_one_work+0x1e5/0x3b0<br /> <br /> indeed the driver does not hold rtnl_lock during its internal close<br /> and re-open functions during suspend/resume. Note that this is not<br /> a huge bug as the driver implements its own locking, and does not<br /> implement changing the number of queues, but we need to silence<br /> the splat.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binfmt_misc: fix shift-out-of-bounds in check_special_flags<br /> <br /> UBSAN reported a shift-out-of-bounds warning:<br /> <br /> left shift of 1 by 31 places cannot be represented in type &amp;#39;int&amp;#39;<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106<br /> ubsan_epilogue+0xa/0x44 lib/ubsan.c:151<br /> __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322<br /> check_special_flags fs/binfmt_misc.c:241 [inline]<br /> create_entry fs/binfmt_misc.c:456 [inline]<br /> bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654<br /> vfs_write+0x11e/0x580 fs/read_write.c:582<br /> ksys_write+0xcf/0x120 fs/read_write.c:637<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x4194e1<br /> <br /> Since the type of Node&amp;#39;s flags is unsigned long, we should define these<br /> macros with same type too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix use-after-free on probe deferral<br /> <br /> The bridge counter was never reset when tearing down the DRM device so<br /> that stale pointers to deallocated structures would be accessed on the<br /> next tear down (e.g. after a second late bind deferral).<br /> <br /> Given enough bridges and a few probe deferrals this could currently also<br /> lead to data beyond the bridge array being corrupted.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/502665/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix crash when I/O abort times out<br /> <br /> While performing CPU hotplug, a crash with the following stack was seen:<br /> <br /> Call Trace:<br /> qla24xx_process_response_queue+0x42a/0x970 [qla2xxx]<br /> qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx]<br /> qla_nvme_post_cmd+0x166/0x240 [qla2xxx]<br /> nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc]<br /> blk_mq_dispatch_rq_list+0x17b/0x610<br /> __blk_mq_sched_dispatch_requests+0xb0/0x140<br /> blk_mq_sched_dispatch_requests+0x30/0x60<br /> __blk_mq_run_hw_queue+0x35/0x90<br /> __blk_mq_delay_run_hw_queue+0x161/0x180<br /> blk_execute_rq+0xbe/0x160<br /> __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core]<br /> nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics]<br /> nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc]<br /> nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc]<br /> process_one_work+0x1e8/0x3c0<br /> <br /> On abort timeout, completion was called without checking if the I/O was<br /> already completed.<br /> <br /> Verify that I/O and abort request are indeed outstanding before attempting<br /> completion.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash<br /> <br /> When CPU 0 is offline and intel_powerclamp is used to inject<br /> idle, it generates kernel BUG:<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687<br /> caller is debug_smp_processor_id+0x17/0x20<br /> CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x49/0x63<br /> dump_stack+0x10/0x16<br /> check_preemption_disabled+0xdd/0xe0<br /> debug_smp_processor_id+0x17/0x20<br /> powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]<br /> ...<br /> ...<br /> <br /> Here CPU 0 is the control CPU by default and changed to the current CPU,<br /> if CPU 0 offlined. This check has to be performed under cpus_read_lock(),<br /> hence the above warning.<br /> <br /> Use get_cpu() instead of smp_processor_id() to avoid this BUG.<br /> <br /> [ rjw: Subject edits ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: cti: Fix hang in cti_disable_hw()<br /> <br /> cti_enable_hw() and cti_disable_hw() are called from an atomic context<br /> so shouldn&amp;#39;t use runtime PM because it can result in a sleep when<br /> communicating with firmware.<br /> <br /> Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock<br /> management to the SCMI power domain""), this causes a hang on Juno when<br /> running the Perf Coresight tests or running this command:<br /> <br /> perf record -e cs_etm//u -- ls<br /> <br /> This was also missed until the revert commit because pm_runtime_put()<br /> was called with the wrong device until commit 692c9a499b28 ("coresight:<br /> cti: Correct the parameter for pm_runtime_put")<br /> <br /> With lock and scheduler debugging enabled the following is output:<br /> <br /> coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti<br /> BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151<br /> in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec<br /> preempt_count: 2, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> INFO: lockdep is turned off.<br /> irq event stamp: 0<br /> hardirqs last enabled at (0): [] 0x0<br /> hardirqs last disabled at (0): [] copy_process+0xa0c/0x1948<br /> softirqs last enabled at (0): [] copy_process+0xa0c/0x1948<br /> softirqs last disabled at (0): [] 0x0<br /> CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7<br /> Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022<br /> Call trace:<br /> dump_backtrace+0x134/0x140<br /> show_stack+0x20/0x58<br /> dump_stack_lvl+0x8c/0xb8<br /> dump_stack+0x18/0x34<br /> __might_resched+0x180/0x228<br /> __might_sleep+0x50/0x88<br /> __pm_runtime_resume+0xac/0xb0<br /> cti_enable+0x44/0x120<br /> coresight_control_assoc_ectdev+0xc0/0x150<br /> coresight_enable_path+0xb4/0x288<br /> etm_event_start+0x138/0x170<br /> etm_event_add+0x48/0x70<br /> event_sched_in.isra.122+0xb4/0x280<br /> merge_sched_in+0x1fc/0x3d0<br /> visit_groups_merge.constprop.137+0x16c/0x4b0<br /> ctx_sched_in+0x114/0x1f0<br /> perf_event_sched_in+0x60/0x90<br /> ctx_resched+0x68/0xb0<br /> perf_event_exec+0x138/0x508<br /> begin_new_exec+0x52c/0xd40<br /> load_elf_binary+0x6b8/0x17d0<br /> bprm_execve+0x360/0x7f8<br /> do_execveat_common.isra.47+0x218/0x238<br /> __arm64_sys_execve+0x48/0x60<br /> invoke_syscall+0x4c/0x110<br /> el0_svc_common.constprop.4+0xfc/0x120<br /> do_el0_svc+0x34/0xc0<br /> el0_svc+0x40/0x98<br /> el0t_64_sync_handler+0x98/0xc0<br /> el0t_64_sync+0x170/0x174<br /> <br /> Fix the issue by removing the runtime PM calls completely. They are not<br /> needed here because it must have already been done when building the<br /> path for a trace.<br /> <br /> [ Fix build warnings ]

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix potential memory leaks<br /> <br /> When the driver hits -ENOMEM at allocating a URB or a buffer, it<br /> aborts and goes to the error path that releases the all previously<br /> allocated resources. However, when -ENOMEM hits at the middle of the<br /> sync EP URB allocation loop, the partially allocated URBs might be<br /> left without released, because ep-&gt;nurbs is still zero at that point.<br /> <br /> Fix it by setting ep-&gt;nurbs at first, so that the error handler loops<br /> over the full URB list.