Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: hi846: fix usage of pm_runtime_get_if_in_use()<br /> <br /> pm_runtime_get_if_in_use() does not only return nonzero values when<br /> the device is in use, it can return a negative errno too.<br /> <br /> And especially during resuming from system suspend, when runtime pm<br /> is not yet up again, -EAGAIN is being returned, so the subsequent<br /> pm_runtime_put() call results in a refcount underflow.<br /> <br /> Fix system-resume by handling -EAGAIN of pm_runtime_get_if_in_use().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix possible memory leak if device_add() fails<br /> <br /> If device_add() returns error, the name allocated by dev_set_name() needs<br /> be freed. As the comment of device_add() says, put_device() should be used<br /> to decrease the reference count in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanp().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: pcn_uart: 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<br /> at once.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds<br /> <br /> Commit 56124d6c87fd ("fsverity: support enabling with tree block size f_mode &amp; FMODE_READ))&amp;#39; in __kernel_read() became<br /> reachable by fuzz tests. This happens if FS_IOC_ENABLE_VERITY is called<br /> on a fd opened with access mode 3, which means "ioctl access only".<br /> <br /> Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds. But<br /> ioctl-only fds are a weird Linux extension that is rarely used and that<br /> few people even know about. (The documentation for FS_IOC_ENABLE_VERITY<br /> even specifically says it requires O_RDONLY.) It&amp;#39;s probably not<br /> worthwhile to make the ioctl internally open a new fd just to handle<br /> this case. Thus, just reject the ioctl on such fds for now.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix uninitialized array access for some pathnames<br /> <br /> For filenames that begin with . and are between 2 and 5 characters long,<br /> UDF charset conversion code would read uninitialized memory in the<br /> output buffer. The only practical impact is that the name may be prepended a<br /> "unification hash" when it is not actually needed but still it is good<br /> to fix this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: bq25890: Fix external_power_changed race<br /> <br /> bq25890_charger_external_power_changed() dereferences bq-&gt;charger,<br /> which gets sets in bq25890_power_supply_init() like this:<br /> <br /> bq-&gt;charger = devm_power_supply_register(bq-&gt;dev, &amp;bq-&gt;desc, &amp;psy_cfg);<br /> <br /> As soon as devm_power_supply_register() has called device_add()<br /> the external_power_changed callback can get called. So there is a window<br /> where bq25890_charger_external_power_changed() may get called while<br /> bq-&gt;charger has not been set yet leading to a NULL pointer dereference.<br /> <br /> This race hits during boot sometimes on a Lenovo Yoga Book 1 yb1-x90f<br /> when the cht_wcove_pwrsrc (extcon) power_supply is done with detecting<br /> the connected charger-type which happens to exactly hit the small window:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> <br /> RIP: 0010:__power_supply_is_supplied_by+0xb/0xb0<br /> <br /> Call Trace:<br /> <br /> __power_supply_get_supplier_property+0x19/0x50<br /> class_for_each_device+0xb1/0xe0<br /> power_supply_get_property_from_supplier+0x2e/0x50<br /> bq25890_charger_external_power_changed+0x38/0x1b0 [bq25890_charger]<br /> __power_supply_changed_work+0x30/0x40<br /> class_for_each_device+0xb1/0xe0<br /> power_supply_changed_work+0x5f/0xe0<br /> <br /> <br /> Fixing this is easy. The external_power_changed callback gets passed<br /> the power_supply which will eventually get stored in bq-&gt;charger,<br /> so bq25890_charger_external_power_changed() can simply directly use<br /> the passed in psy argument which is always valid.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix null pointer dereference in tracing_err_log_open()<br /> <br /> Fix an issue in function &amp;#39;tracing_err_log_open&amp;#39;.<br /> The function doesn&amp;#39;t call &amp;#39;seq_open&amp;#39; if the file is opened only with<br /> write permissions, which results in &amp;#39;file-&gt;private_data&amp;#39; being left as null.<br /> If we then use &amp;#39;lseek&amp;#39; on that opened file, &amp;#39;seq_lseek&amp;#39; dereferences<br /> &amp;#39;file-&gt;private_data&amp;#39; in &amp;#39;mutex_lock(&amp;m-&gt;lock)&amp;#39;, resulting in a kernel panic.<br /> Writing to this node requires root privileges, therefore this bug<br /> has very little security impact.<br /> <br /> Tracefs node: /sys/kernel/tracing/error_log<br /> <br /> Example Kernel panic:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038<br /> Call trace:<br /> mutex_lock+0x30/0x110<br /> seq_lseek+0x34/0xb8<br /> __arm64_sys_lseek+0x6c/0xb8<br /> invoke_syscall+0x58/0x13c<br /> el0_svc_common+0xc4/0x10c<br /> do_el0_svc+0x24/0x98<br /> el0_svc+0x24/0x88<br /> el0t_64_sync_handler+0x84/0xe4<br /> el0t_64_sync+0x1b4/0x1b8<br /> Code: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02)<br /> ---[ end trace 561d1b49c12cf8a5 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: ucsi_acpi: Increase the command completion timeout<br /> <br /> Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command<br /> completion timeout value") increased the timeout from 5 seconds<br /> to 60 seconds due to issues related to alternate mode discovery.<br /> <br /> After the alternate mode discovery switch to polled mode<br /> the timeout was reduced, but instead of being set back to<br /> 5 seconds it was reduced to 1 second.<br /> <br /> This is causing problems when using a Lenovo ThinkPad X1 yoga gen7<br /> connected over Type-C to a LG 27UL850-W (charging DP over Type-C).<br /> <br /> When the monitor is already connected at boot the following error<br /> is logged: "PPM init failed (-110)", /sys/class/typec is empty and<br /> on unplugging the NULL pointer deref fixed earlier in this series<br /> happens.<br /> <br /> When the monitor is connected after boot the following error<br /> is logged instead: "GET_CONNECTOR_STATUS failed (-110)".<br /> <br /> Setting the timeout back to 5 seconds fixes both cases.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/type1: prevent underflow of locked_vm via exec()<br /> <br /> When a vfio container is preserved across exec, the task does not change,<br /> but it gets a new mm with locked_vm=0, and loses the count from existing<br /> dma mappings. If the user later unmaps a dma mapping, locked_vm underflows<br /> to a large unsigned value, and a subsequent dma map request fails with<br /> ENOMEM in __account_locked_vm.<br /> <br /> To avoid underflow, grab and save the mm at the time a dma is mapped.<br /> Use that mm when adjusting locked_vm, rather than re-acquiring the saved<br /> task&amp;#39;s mm, which may have changed. If the saved mm is dead, do nothing.<br /> <br /> locked_vm is incremented for existing mappings in a subsequent patch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: Removed unneeded of_node_put in felix_parse_ports_node<br /> <br /> Remove unnecessary of_node_put from the continue path to prevent<br /> child node from being released twice, which could avoid resource<br /> leak or other unexpected issues.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/resctrl: Clear staged_config[] before and after it is used<br /> <br /> As a temporary storage, staged_config[] in rdt_domain should be cleared<br /> before and after it is used. The stale value in staged_config[] could<br /> cause an MSR access error.<br /> <br /> Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3<br /> Cache (MBA should be disabled if the number of CLOSIDs for MB is less than<br /> 16.) :<br /> mount -t resctrl resctrl -o cdp /sys/fs/resctrl<br /> mkdir /sys/fs/resctrl/p{1..7}<br /> umount /sys/fs/resctrl/<br /> mount -t resctrl resctrl /sys/fs/resctrl<br /> mkdir /sys/fs/resctrl/p{1..8}<br /> <br /> An error occurs when creating resource group named p8:<br /> unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)<br /> Call Trace:<br /> <br /> __flush_smp_call_function_queue+0x11d/0x170<br /> __sysvec_call_function+0x24/0xd0<br /> sysvec_call_function+0x89/0xc0<br /> <br /> <br /> asm_sysvec_call_function+0x16/0x20<br /> <br /> When creating a new resource control group, hardware will be configured<br /> by the following process:<br /> rdtgroup_mkdir()<br /> rdtgroup_mkdir_ctrl_mon()<br /> rdtgroup_init_alloc()<br /> resctrl_arch_update_domains()<br /> <br /> resctrl_arch_update_domains() iterates and updates all resctrl_conf_type<br /> whose have_new_ctrl is true. Since staged_config[] holds the same values as<br /> when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA<br /> configurations. When group p8 is created, get_config_index() called in<br /> resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for<br /> CDP_CODE and CDP_DATA, which will be translated to an invalid register -<br /> 0xca0 in this scenario.<br /> <br /> Fix it by clearing staged_config[] before and after it is used.<br /> <br /> [reinette: re-order commit tags]