Vulnerabilities

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.

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.

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().

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.

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.

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix zswap writeback race condition<br /> <br /> The zswap writeback mechanism can cause a race condition resulting in<br /> memory corruption, where a swapped out page gets swapped in with data that<br /> was written to a different page.<br /> <br /> The race unfolds like this:<br /> 1. a page with data A and swap offset X is stored in zswap<br /> 2. page A is removed off the LRU by zpool driver for writeback in<br /> zswap-shrink work, data for A is mapped by zpool driver<br /> 3. user space program faults and invalidates page entry A, offset X is<br /> considered free<br /> 4. kswapd stores page B at offset X in zswap (zswap could also be<br /> full, if so, page B would then be IOed to X, then skip step 5.)<br /> 5. entry A is replaced by B in tree-&gt;rbroot, this doesn&amp;#39;t affect the<br /> local reference held by zswap-shrink work<br /> 6. zswap-shrink work writes back A at X, and frees zswap entry A<br /> 7. swapin of slot X brings A in memory instead of B<br /> <br /> The fix:<br /> Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),<br /> zswap-shrink work just checks that the local zswap_entry reference is<br /> still the same as the one in the tree. If it&amp;#39;s not the same it means that<br /> it&amp;#39;s either been invalidated or replaced, in both cases the writeback is<br /> aborted because the local entry contains stale data.<br /> <br /> Reproducer:<br /> I originally found this by running `stress` overnight to validate my work<br /> on the zswap writeback mechanism, it manifested after hours on my test<br /> machine. The key to make it happen is having zswap writebacks, so<br /> whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do<br /> the trick.<br /> <br /> In order to reproduce this faster on a vm, I setup a system with ~100M of<br /> available memory and a 500M swap file, then running `stress --vm 1<br /> --vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens<br /> of minutes. One can speed things up even more by swinging<br /> /sys/module/zswap/parameters/max_pool_percent up and down between, say, 20<br /> and 1; this makes it reproduce in tens of seconds. It&amp;#39;s crucial to set<br /> `--vm-stride` to something other than 4096 otherwise `stress` won&amp;#39;t<br /> realize that memory has been corrupted because all pages would have the<br /> same data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c<br /> <br /> The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can<br /> lead to the use of wrong `CIDR_POS(c)` for calculating array offsets,<br /> which can lead to integer underflow. As a result, it leads to slab<br /> out-of-bound access.<br /> This patch adds back the IP_SET_HASH_WITH_NET0 macro to<br /> ip_set_hash_netportnet to address the issue.

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.

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.

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.

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