Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: vmbus: Check for channel allocation before looking up relids<br /> <br /> relid2channel() assumes vmbus channel array to be allocated when called.<br /> However, in cases such as kdump/kexec, not all relids will be reset by the host.<br /> When the second kernel boots and if the guest receives a vmbus interrupt during<br /> vmbus driver initialization before vmbus_connect() is called, before it finishes,<br /> or if it fails, the vmbus interrupt service routine is called which in turn calls<br /> relid2channel() and can cause a null pointer dereference.<br /> <br /> Print a warning and error out in relid2channel() for a channel id that&amp;#39;s invalid<br /> in the second kernel.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: mt8183: Add back SSPM related clocks<br /> <br /> This reverts commit 860690a93ef23b567f781c1b631623e27190f101.<br /> <br /> On the MT8183, the SSPM related clocks were removed claiming a lack of<br /> usage. This however causes some issues when the driver was converted to<br /> the new simple-probe mechanism. This mechanism allocates enough space<br /> for all the clocks defined in the clock driver, not the highest index<br /> in the DT binding. This leads to out-of-bound writes if their are holes<br /> in the DT binding or the driver (due to deprecated or unimplemented<br /> clocks). These errors can go unnoticed and cause memory corruption,<br /> leading to crashes in unrelated areas, or nothing at all. KASAN will<br /> detect them.<br /> <br /> Add the SSPM related clocks back to the MT8183 clock driver to fully<br /> implement the DT binding. The SSPM clocks are for the power management<br /> co-processor, and should never be turned off. They are marked as such.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()<br /> <br /> The variable codec-&gt;regmap is often protected by the lock<br /> codec-&gt;regmap_lock when is accessed. However, it is accessed without<br /> holding the lock when is accessed in snd_hdac_regmap_sync():<br /> <br /> if (codec-&gt;regmap)<br /> <br /> In my opinion, this may be a harmful race, because if codec-&gt;regmap is<br /> set to NULL right after the condition is checked, a null-pointer<br /> dereference can occur in the called function regcache_sync():<br /> <br /> map-&gt;lock(map-&gt;lock_arg); --&gt; Line 360 in drivers/base/regmap/regcache.c<br /> <br /> To fix this possible null-pointer dereference caused by data race, the<br /> mutex_lock coverage is extended to protect the if statement as well as the<br /> function call to regcache_sync().<br /> <br /> [ Note: the lack of the regmap_lock itself is harmless for the current<br /> codec driver implementations, as snd_hdac_regmap_sync() is only for<br /> PM runtime resume that is prohibited during the codec probe.<br /> But the change makes the whole code more consistent, so it&amp;#39;s merged<br /> as is -- tiwai ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Free memory for tmpfile name<br /> <br /> When opening a ubifs tmpfile on an encrypted directory, function<br /> fscrypt_setup_filename allocates memory for the name that is to be<br /> stored in the directory entry, but after the name has been copied to the<br /> directory entry inode, the memory is not freed.<br /> <br /> When running kmemleak on it we see that it is registered as a leak. The<br /> report below is triggered by a simple program &amp;#39;tmpfile&amp;#39; just opening a<br /> tmpfile:<br /> <br /> unreferenced object 0xffff88810178f380 (size 32):<br /> comm "tmpfile", pid 509, jiffies 4294934744 (age 1524.742s)<br /> backtrace:<br /> __kmem_cache_alloc_node<br /> __kmalloc<br /> fscrypt_setup_filename<br /> ubifs_tmpfile<br /> vfs_tmpfile<br /> path_openat<br /> <br /> Free this memory after it has been copied to the inode.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwl3945: Add missing check for create_singlethread_workqueue<br /> <br /> Add the check for the return value of the create_singlethread_workqueue<br /> in order to avoid NULL pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix memory leak in ubifs_sysfs_init()<br /> <br /> When insmod ubifs.ko, a kmemleak reported as below:<br /> <br /> unreferenced object 0xffff88817fb1a780 (size 8):<br /> comm "insmod", pid 25265, jiffies 4295239702 (age 100.130s)<br /> hex dump (first 8 bytes):<br /> 75 62 69 66 73 00 ff ff ubifs...<br /> backtrace:<br /> [] slab_post_alloc_hook+0x9c/0x3c0<br /> [] __kmalloc_track_caller+0x183/0x410<br /> [] kstrdup+0x3a/0x80<br /> [] kstrdup_const+0x66/0x80<br /> [] kvasprintf_const+0x155/0x190<br /> [] kobject_set_name_vargs+0x5b/0x150<br /> [] kobject_set_name+0xbb/0xf0<br /> [] do_one_initcall+0x14c/0x5a0<br /> [] do_init_module+0x1f0/0x660<br /> [] load_module+0x6d7e/0x7590<br /> [] __do_sys_finit_module+0x19f/0x230<br /> [] __x64_sys_finit_module+0x73/0xb0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> When kset_register() failed, we should call kset_put to cleanup it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: vmw_balloon: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic at<br /> once.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue<br /> <br /> System crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_up<br /> gets called for uninitialized wait queue sp-&gt;nvme_ls_waitq.<br /> <br /> qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0<br /> qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11<br /> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021<br /> Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]<br /> RIP: 0010:__wake_up_common+0x4c/0x190<br /> RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086<br /> RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8<br /> R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20<br /> R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> __wake_up_common_lock+0x7c/0xc0<br /> qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]<br /> ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]<br /> ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]<br /> ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]<br /> <br /> Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removed<br /> previously in the commits tagged Fixed: below.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe<br /> <br /> Use devm_of_iomap() instead of of_iomap() to automatically<br /> handle the unused ioremap region. If any error occurs, regions allocated by<br /> kzalloc() will leak, but using devm_kzalloc() instead will automatically<br /> free the memory using devm_kfree().<br /> <br /> Also, fix error handling of hws by adding unregister_hws label, which<br /> unregisters remaining hws when iomap failed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: ensure that VID header offset + VID header size

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: acpi: Fix possible memory leak of ffh_ctxt<br /> <br /> Allocated &amp;#39;ffh_ctxt&amp;#39; memory leak is possible if the SMCCC version<br /> and conduit checks fail and -EOPNOTSUPP is returned without freeing the<br /> allocated memory.<br /> <br /> Fix the same by moving the allocation after the SMCCC version and<br /> conduit checks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event()<br /> <br /> The kfree() should be called when memory fails to be allocated for<br /> cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be<br /> a memory leak, so add kfree() to fix it.