Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: runflags cannot determine whether to reclaim chanlist<br /> <br /> syzbot reported a memory leak [1], because commit 4e1da516debb ("comedi:<br /> Add reference counting for Comedi command handling") did not consider<br /> the exceptional exit case in do_cmd_ioctl() where runflags is not set.<br /> This caused chanlist not to be properly freed by do_become_nonbusy(),<br /> as it only frees chanlist when runflags is correctly set.<br /> <br /> Added a check in do_become_nonbusy() for the case where runflags is not<br /> set, to properly free the chanlist memory.<br /> <br /> [1]<br /> BUG: memory leak<br /> backtrace (crc 844a0efa):<br /> __comedi_get_user_chanlist drivers/comedi/comedi_fops.c:1815 [inline]<br /> do_cmd_ioctl.part.0+0x112/0x350 drivers/comedi/comedi_fops.c:1890<br /> do_cmd_ioctl drivers/comedi/comedi_fops.c:1858 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: ni_atmio16d: Fix invalid clean-up after failed attach<br /> <br /> If the driver&amp;#39;s COMEDI "attach" handler function (`atmio16d_attach()`)<br /> returns an error, the COMEDI core will call the driver&amp;#39;s "detach"<br /> handler function (`atmio16d_detach()`) to clean up. This calls<br /> `reset_atmio16d()` unconditionally, but depending on where the error<br /> occurred in the attach handler, the device may not have been<br /> sufficiently initialized to call `reset_atmio16d()`. It uses<br /> `dev-&gt;iobase` as the I/O port base address and `dev-&gt;private` as the<br /> pointer to the COMEDI device&amp;#39;s private data structure. `dev-&gt;iobase`<br /> may still be set to its initial value of 0, which would result in<br /> undesired writes to low I/O port addresses. `dev-&gt;private` may still be<br /> `NULL`, which would result in null pointer dereferences.<br /> <br /> Fix `atmio16d_detach()` by checking that `dev-&gt;private` is valid<br /> (non-null) before calling `reset_atmio16d()`. This implies that<br /> `dev-&gt;iobase` was set correctly since that is set up before<br /> `dev-&gt;private`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: me_daq: Fix potential overrun of firmware buffer<br /> <br /> `me2600_xilinx_download()` loads the firmware that was requested by<br /> `request_firmware()`. It is possible for it to overrun the source<br /> buffer because it blindly trusts the file format. It reads a data<br /> stream length from the first 4 bytes into variable `file_length` and<br /> reads the data stream contents of length `file_length` from offset 16<br /> onwards. Although it checks that the supplied firmware is at least 16<br /> bytes long, it does not check that it is long enough to contain the data<br /> stream.<br /> <br /> Add a test to ensure that the supplied firmware is long enough to<br /> contain the header and the data stream. On failure, log an error and<br /> return `-EINVAL`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: me4000: Fix potential overrun of firmware buffer<br /> <br /> `me4000_xilinx_download()` loads the firmware that was requested by<br /> `request_firmware()`. It is possible for it to overrun the source<br /> buffer because it blindly trusts the file format. It reads a data<br /> stream length from the first 4 bytes into variable `file_length` and<br /> reads the data stream contents of length `file_length` from offset 16<br /> onwards.<br /> <br /> Add a test to ensure that the supplied firmware is long enough to<br /> contain the header and the data stream. On failure, log an error and<br /> return `-EINVAL`.<br /> <br /> Note: The firmware loading was totally broken before commit ac584af59945<br /> ("staging: comedi: me4000: fix firmware downloading"), but that is the<br /> most sensible target for this fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/zcrypt: Fix memory leak with CCA cards used as accelerator<br /> <br /> Tests showed that there is a memory leak if CCA cards are used as<br /> accelerator for clear key RSA requests (ME and CRT). With the last<br /> rework for the memory allocation the AP messages are allocated by<br /> ap_init_apmsg() but for some reason on two places (ME and CRT) the<br /> older allocation was still in place. So the first allocation simple<br /> was never freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> reset: gpio: fix double free in reset_add_gpio_aux_device() error path<br /> <br /> When __auxiliary_device_add() fails, reset_add_gpio_aux_device()<br /> calls auxiliary_device_uninit(adev).<br /> <br /> The device release callback reset_gpio_aux_device_release() frees<br /> adev, but the current error path then calls kfree(adev) again,<br /> causing a double free.<br /> <br /> Keep kfree(adev) for the auxiliary_device_init() failure path, but<br /> avoid freeing adev after auxiliary_device_uninit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: EM: Fix NULL pointer dereference when perf domain ID is not found<br /> <br /> dev_energymodel_nl_get_perf_domains_doit() calls<br /> em_perf_domain_get_by_id() but does not check the return value before<br /> passing it to __em_nl_get_pd_size(). When a caller supplies a<br /> non-existent perf domain ID, em_perf_domain_get_by_id() returns NULL,<br /> and __em_nl_get_pd_size() immediately dereferences pd-&gt;cpus<br /> (struct offset 0x30), causing a NULL pointer dereference.<br /> <br /> The sister handler dev_energymodel_nl_get_perf_table_doit() already<br /> handles this correctly via __em_nl_get_pd_table_id(), which returns<br /> NULL and causes the caller to return -EINVAL. Add the same NULL check<br /> in the get-perf-domains do handler.<br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: zynqmp_nvmem: Fix buffer size in DMA and memcpy<br /> <br /> Buffer size used in dma allocation and memcpy is wrong.<br /> It can lead to undersized DMA buffer access and possible<br /> memory corruption. use correct buffer size in dma_alloc_coherent<br /> and memcpy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix is_bpf_migration_disabled() false negative on non-PREEMPT_RCU<br /> <br /> Since commit 8e4f0b1ebcf2 ("bpf: use rcu_read_lock_dont_migrate() for<br /> trampoline.c"), the BPF prolog (__bpf_prog_enter) calls migrate_disable()<br /> only when CONFIG_PREEMPT_RCU is enabled, via rcu_read_lock_dont_migrate().<br /> Without CONFIG_PREEMPT_RCU, the prolog never touches migration_disabled,<br /> so migration_disabled == 1 always means the task is truly<br /> migration-disabled regardless of whether it is the current task.<br /> <br /> The old unconditional p == current check was a false negative in this<br /> case, potentially allowing a migration-disabled task to be dispatched to<br /> a remote CPU and triggering scx_error in task_can_run_on_remote_rq().<br /> <br /> Only apply the p == current disambiguation when CONFIG_PREEMPT_RCU is<br /> enabled, where the ambiguity with the BPF prolog still exists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommupt: Fix short gather if the unmap goes into a large mapping<br /> <br /> unmap has the odd behavior that it can unmap more than requested if the<br /> ending point lands within the middle of a large or contiguous IOPTE.<br /> <br /> In this case the gather should flush everything unmapped which can be<br /> larger than what was requested to be unmapped. The gather was only<br /> flushing the range requested to be unmapped, not extending to the extra<br /> range, resulting in a short invalidation if the caller hits this special<br /> condition.<br /> <br /> This was found by the new invalidation/gather test I am adding in<br /> preparation for ARMv8. Claude deduced the root cause.<br /> <br /> As far as I remember nothing relies on unmapping a large entry, so this is<br /> likely not a triggerable bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_ppe: avoid NULL deref when gmac0 is disabled<br /> <br /> If the gmac0 is disabled, the precheck for a valid ingress device will<br /> cause a NULL pointer deref and crash the system. This happens because<br /> eth-&gt;netdev[0] will be NULL but the code will directly try to access<br /> netdev_ops.<br /> <br /> Instead of just checking for the first net_device, it must be checked if<br /> any of the mtk_eth net_devices is matching the netdev_ops of the ingress<br /> device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: discard stale unicode buffer on alt screen exit after resize<br /> <br /> When enter_alt_screen() saves vc_uni_lines into vc_saved_uni_lines and<br /> sets vc_uni_lines to NULL, a subsequent console resize via vc_do_resize()<br /> skips reallocating the unicode buffer because vc_uni_lines is NULL.<br /> However, vc_saved_uni_lines still points to the old buffer allocated for<br /> the original dimensions.<br /> <br /> When leave_alt_screen() later restores vc_saved_uni_lines, the buffer<br /> dimensions no longer match vc_rows/vc_cols. Any operation that iterates<br /> over the unicode buffer using the current dimensions (e.g. csi_J clearing<br /> the screen) will access memory out of bounds, causing a kernel oops:<br /> <br /> BUG: unable to handle page fault for address: 0x0000002000000020<br /> RIP: 0010:csi_J+0x133/0x2d0<br /> <br /> The faulting address 0x0000002000000020 is two adjacent u32 space<br /> characters (0x20) interpreted as a pointer, read from the row data area<br /> past the end of the 25-entry pointer array in a buffer allocated for<br /> 80x25 but accessed with 240x67 dimensions.<br /> <br /> Fix this by checking whether the console dimensions changed while in the<br /> alternate screen. If they did, free the stale saved buffer instead of<br /> restoring it. The unicode screen will be lazily rebuilt via<br /> vc_uniscr_check() when next needed.