Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: Reinit port-&gt;pm on port specific driver unbind<br /> <br /> When we unbind a serial port hardware specific 8250 driver, the generic<br /> serial8250 driver takes over the port. After that we see an oops about 10<br /> seconds later. This can produce the following at least on some TI SoCs:<br /> <br /> Unhandled fault: imprecise external abort (0x1406)<br /> Internal error: : 1406 [#1] SMP ARM<br /> <br /> Turns out that we may still have the serial port hardware specific driver<br /> port-&gt;pm in use, and serial8250_pm() tries to call it after the port<br /> specific driver is gone:<br /> <br /> serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]<br /> uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]<br /> uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c<br /> __tty_hangup.part.0 from disassociate_ctty+0x154/0x20c<br /> disassociate_ctty from do_exit+0x744/0xaac<br /> do_exit from do_group_exit+0x40/0x8c<br /> do_group_exit from __wake_up_parent+0x0/0x1c<br /> <br /> Let&amp;#39;s fix the issue by calling serial8250_set_defaults() in<br /> serial8250_unregister_port(). This will set the port back to using<br /> the serial8250 default functions, and sets the port-&gt;pm to point to<br /> serial8250_pm.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: hv: Fix a crash in hv_pci_restore_msi_msg() during hibernation<br /> <br /> When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI<br /> device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the<br /> device yet), doing a VM hibernation triggers a panic in<br /> hv_pci_restore_msi_msg() -&gt; msi_lock_descs(&amp;pdev-&gt;dev), because<br /> pdev-&gt;dev.msi.data is still NULL.<br /> <br /> Avoid the panic by checking if MSI-X/MSI is enabled.

*** 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.