Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: thp: deny THP for files on anonymous inodes<br /> <br /> file_thp_enabled() incorrectly allows THP for files on anonymous inodes<br /> (e.g. guest_memfd and secretmem). These files are created via<br /> alloc_file_pseudo(), which does not call get_write_access() and leaves<br /> inode-&gt;i_writecount at 0. Combined with S_ISREG(inode-&gt;i_mode) being<br /> true, they appear as read-only regular files when<br /> CONFIG_READ_ONLY_THP_FOR_FS is enabled, making them eligible for THP<br /> collapse.<br /> <br /> Anonymous inodes can never pass the inode_is_open_for_write() check<br /> since their i_writecount is never incremented through the normal VFS<br /> open path. The right thing to do is to exclude them from THP eligibility<br /> altogether, since CONFIG_READ_ONLY_THP_FOR_FS was designed for real<br /> filesystem files (e.g. shared libraries), not for pseudo-filesystem<br /> inodes.<br /> <br /> For guest_memfd, this allows khugepaged and MADV_COLLAPSE to create<br /> large folios in the page cache via the collapse path, but the<br /> guest_memfd fault handler does not support large folios. This triggers<br /> WARN_ON_ONCE(folio_test_large(folio)) in kvm_gmem_fault_user_mapping().<br /> <br /> For secretmem, collapse_file() tries to copy page contents through the<br /> direct map, but secretmem pages are removed from the direct map. This<br /> can result in a kernel crash:<br /> <br /> BUG: unable to handle page fault for address: ffff88810284d000<br /> RIP: 0010:memcpy_orig+0x16/0x130<br /> Call Trace:<br /> collapse_file<br /> hpage_collapse_scan_file<br /> madvise_collapse<br /> <br /> Secretmem is not affected by the crash on upstream as the memory failure<br /> recovery handles the failed copy gracefully, but it still triggers<br /> confusing false memory failure reports:<br /> <br /> Memory failure: 0x106d96f: recovery action for clean unevictable<br /> LRU page: Recovered<br /> <br /> Check IS_ANON_FILE(inode) in file_thp_enabled() to deny THP for all<br /> anonymous inode files.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: radiotap: reject radiotap with unknown bits<br /> <br /> The radiotap parser is currently only used with the radiotap<br /> namespace (not with vendor namespaces), but if the undefined<br /> field 18 is used, the alignment/size is unknown as well. In<br /> this case, iterator-&gt;_next_ns_data isn&amp;#39;t initialized (it&amp;#39;s<br /> only set for skipping vendor namespaces), and syzbot points<br /> out that we later compare against this uninitialized value.<br /> <br /> Fix this by moving the rejection of unknown radiotap fields<br /> down to after the in-namespace lookup, so it will really use<br /> iterator-&gt;_next_ns_data only for vendor namespaces, even in<br /> case undefined fields are present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: register phy led_triggers during probe to avoid AB-BA deadlock<br /> <br /> There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and<br /> LED_TRIGGER_PHY are enabled:<br /> <br /> [ 1362.049207] [] led_trigger_register+0x5c/0x1fc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rsi: Don&amp;#39;t default to -EOPNOTSUPP in rsi_mac80211_config<br /> <br /> This triggers a WARN_ON in ieee80211_hw_conf_init and isn&amp;#39;t the expected<br /> behavior from the driver - other drivers default to 0 too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: rawsock: cancel tx_work before socket teardown<br /> <br /> In rawsock_release(), cancel any pending tx_work and purge the write<br /> queue before orphaning the socket. rawsock_tx_work runs on the system<br /> workqueue and calls nfc_data_exchange which dereferences the NCI<br /> device. Without synchronization, tx_work can race with socket and<br /> device teardown when a process is killed (e.g. by SIGKILL), leading<br /> to use-after-free or leaked references.<br /> <br /> Set SEND_SHUTDOWN first so that if tx_work is already running it will<br /> see the flag and skip transmitting, then use cancel_work_sync to wait<br /> for any in-progress execution to finish, and finally purge any<br /> remaining queued skbs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting<br /> <br /> Running stress-ng --schedpolicy 0 on an RT kernel on a big machine<br /> might lead to the following WARNINGs (edited).<br /> <br /> sched: DL de-boosted task PID 22725: REPLENISH flag missing<br /> <br /> WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8<br /> ... (running_bw underflow)<br /> Call trace:<br /> dequeue_task_dl+0x15c/0x1f8 (P)<br /> dequeue_task+0x80/0x168<br /> deactivate_task+0x24/0x50<br /> push_dl_task+0x264/0x2e0<br /> dl_task_timer+0x1b0/0x228<br /> __hrtimer_run_queues+0x188/0x378<br /> hrtimer_interrupt+0xfc/0x260<br /> ...<br /> <br /> The problem is that when a SCHED_DEADLINE task (lock holder) is<br /> changed to a lower priority class via sched_setscheduler(), it may<br /> fail to properly inherit the parameters of potential DEADLINE donors<br /> if it didn&amp;#39;t already inherit them in the past (shorter deadline than<br /> donor&amp;#39;s at that time). This might lead to bandwidth accounting<br /> corruption, as enqueue_task_dl() won&amp;#39;t recognize the lock holder as<br /> boosted.<br /> <br /> The scenario occurs when:<br /> 1. A DEADLINE task (donor) blocks on a PI mutex held by another<br /> DEADLINE task (holder), but the holder doesn&amp;#39;t inherit parameters<br /> (e.g., it already has a shorter deadline)<br /> 2. sched_setscheduler() changes the holder from DEADLINE to a lower<br /> class while still holding the mutex<br /> 3. The holder should now inherit DEADLINE parameters from the donor<br /> and be enqueued with ENQUEUE_REPLENISH, but this doesn&amp;#39;t happen<br /> <br /> Fix the issue by introducing __setscheduler_dl_pi(), which detects when<br /> a DEADLINE (proper or boosted) task gets setscheduled to a lower<br /> priority class. In case, the function makes the task inherit DEADLINE<br /> parameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to<br /> ensure proper bandwidth accounting during the next enqueue operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-wmi-sysman: Don&amp;#39;t hex dump plaintext password data<br /> <br /> set_new_password() hex dumps the entire buffer, which contains plaintext<br /> password data, including current and new passwords. Remove the hex dump<br /> to avoid leaking credentials.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: i801: Revert "i2c: i801: replace acpi_lock with I2C bus lock"<br /> <br /> This reverts commit f707d6b9e7c18f669adfdb443906d46cfbaaa0c1.<br /> <br /> Under rare circumstances, multiple udev threads can collect i801 device<br /> info on boot and walk i801_acpi_io_handler somewhat concurrently. The<br /> first will note the area is reserved by acpi to prevent further touches.<br /> This ultimately causes the area to be deregistered. The second will<br /> enter i801_acpi_io_handler after the area is unregistered but before a<br /> check can be made that the area is unregistered. i2c_lock_bus relies on<br /> the now unregistered area containing lock_ops to lock the bus. The end<br /> result is a kernel panic on boot with the following backtrace;<br /> <br /> [ 14.971872] ioatdma 0000:09:00.2: enabling device (0100 -&gt; 0102)<br /> [ 14.971873] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 14.971880] #PF: supervisor read access in kernel mode<br /> [ 14.971884] #PF: error_code(0x0000) - not-present page<br /> [ 14.971887] PGD 0 P4D 0<br /> [ 14.971894] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 14.971900] CPU: 5 PID: 956 Comm: systemd-udevd Not tainted 5.14.0-611.5.1.el9_7.x86_64 #1<br /> [ 14.971905] Hardware name: XXXXXXXXXXXXXXXXXXXXXXX BIOS 1.20.10.SV91 01/30/2023<br /> [ 14.971908] RIP: 0010:i801_acpi_io_handler+0x2d/0xb0 [i2c_i801]<br /> [ 14.971929] Code: 00 00 49 8b 40 20 41 57 41 56 4d 8b b8 30 04 00 00 49 89 ce 41 55 41 89 d5 41 54 49 89 f4 be 02 00 00 00 55 4c 89 c5 53 89 fb 8b 00 4c 89 c7 e8 18 61 54 e9 80 bd 80 04 00 00 00 75 09 4c 3b<br /> [ 14.971933] RSP: 0018:ffffbaa841483838 EFLAGS: 00010282<br /> [ 14.971938] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9685e01ba568<br /> [ 14.971941] RDX: 0000000000000008 RSI: 0000000000000002 RDI: 0000000000000000<br /> [ 14.971944] RBP: ffff9685ca22f028 R08: ffff9685ca22f028 R09: ffff9685ca22f028<br /> [ 14.971948] R10: 000000000000000b R11: 0000000000000580 R12: 0000000000000580<br /> [ 14.971951] R13: 0000000000000008 R14: ffff9685e01ba568 R15: ffff9685c222f000<br /> [ 14.971954] FS: 00007f8287c0ab40(0000) GS:ffff96a47f940000(0000) knlGS:0000000000000000<br /> [ 14.971959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 14.971963] CR2: 0000000000000000 CR3: 0000000168090001 CR4: 00000000003706f0<br /> [ 14.971966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 14.971968] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 14.971972] Call Trace:<br /> [ 14.971977] <br /> [ 14.971981] ? show_trace_log_lvl+0x1c4/0x2df<br /> [ 14.971994] ? show_trace_log_lvl+0x1c4/0x2df<br /> [ 14.972003] ? acpi_ev_address_space_dispatch+0x16e/0x3c0<br /> [ 14.972014] ? __die_body.cold+0x8/0xd<br /> [ 14.972021] ? page_fault_oops+0x132/0x170<br /> [ 14.972028] ? exc_page_fault+0x61/0x150<br /> [ 14.972036] ? asm_exc_page_fault+0x22/0x30<br /> [ 14.972045] ? i801_acpi_io_handler+0x2d/0xb0 [i2c_i801]<br /> [ 14.972061] acpi_ev_address_space_dispatch+0x16e/0x3c0<br /> [ 14.972069] ? __pfx_i801_acpi_io_handler+0x10/0x10 [i2c_i801]<br /> [ 14.972085] acpi_ex_access_region+0x5b/0xd0<br /> [ 14.972093] acpi_ex_field_datum_io+0x73/0x2e0<br /> [ 14.972100] acpi_ex_read_data_from_field+0x8e/0x230<br /> [ 14.972106] acpi_ex_resolve_node_to_value+0x23d/0x310<br /> [ 14.972114] acpi_ds_evaluate_name_path+0xad/0x110<br /> [ 14.972121] acpi_ds_exec_end_op+0x321/0x510<br /> [ 14.972127] acpi_ps_parse_loop+0xf7/0x680<br /> [ 14.972136] acpi_ps_parse_aml+0x17a/0x3d0<br /> [ 14.972143] acpi_ps_execute_method+0x137/0x270<br /> [ 14.972150] acpi_ns_evaluate+0x1f4/0x2e0<br /> [ 14.972158] acpi_evaluate_object+0x134/0x2f0<br /> [ 14.972164] acpi_evaluate_integer+0x50/0xe0<br /> [ 14.972173] ? vsnprintf+0x24b/0x570<br /> [ 14.972181] acpi_ac_get_state.part.0+0x23/0x70<br /> [ 14.972189] get_ac_property+0x4e/0x60<br /> [ 14.972195] power_supply_show_property+0x90/0x1f0<br /> [ 14.972205] add_prop_uevent+0x29/0x90<br /> [ 14.972213] power_supply_uevent+0x109/0x1d0<br /> [ 14.972222] dev_uevent+0x10e/0x2f0<br /> [ 14.972228] uevent_show+0x8e/0x100<br /> [ 14.972236] dev_attr_show+0x19<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: bcm: fix locking for bcm_op runtime updates<br /> <br /> Commit c2aba69d0c36 ("can: bcm: add locking for bcm_op runtime updates")<br /> added a locking for some variables that can be modified at runtime when<br /> updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup().<br /> <br /> Usually the RX_SETUP only handles and filters incoming traffic with one<br /> exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is<br /> sent when a specific RTR frame is received. Therefore the rx bcm_op uses<br /> bcm_can_tx() which uses the bcm_tx_lock that was only initialized in<br /> bcm_tx_setup(). Add the missing spin_lock_init() when allocating the<br /> bcm_op in bcm_rx_setup() to handle the RTR case properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/client: Do not destroy NULL modes<br /> <br /> &amp;#39;modes&amp;#39; in drm_client_modeset_probe may fail to kcalloc. If this<br /> occurs, we jump to &amp;#39;out&amp;#39;, calling modes_destroy on it, which<br /> dereferences it. This may result in a NULL pointer dereference in the<br /> error case. Prevent that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry<br /> <br /> Endpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X<br /> interrupt to the host using a writel(), which generates a PCI posted write<br /> transaction. There&amp;#39;s no completion for posted writes, so the writel() may<br /> return before the PCI write completes. dw_pcie_ep_raise_msix_irq() also<br /> unmaps the outbound ATU entry used for the PCI write, so the write races<br /> with the unmap.<br /> <br /> If the PCI write loses the race with the ATU unmap, the write may corrupt<br /> host memory or cause IOMMU errors, e.g., these when running fio with a<br /> larger queue depth against nvmet-pci-epf:<br /> <br /> arm-smmu-v3 fc900000.iommu: 0x0000010000000010<br /> arm-smmu-v3 fc900000.iommu: 0x0000020000000000<br /> arm-smmu-v3 fc900000.iommu: 0x000000090000f040<br /> arm-smmu-v3 fc900000.iommu: 0x0000000000000000<br /> arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0<br /> arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0<br /> <br /> Flush the write by performing a readl() of the same address to ensure that<br /> the write has reached the destination before the ATU entry is unmapped.<br /> <br /> The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit<br /> 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but there<br /> it was solved by dedicating an outbound iATU only for MSI. We can&amp;#39;t do the<br /> same for MSI-X because each vector can have a different msg_addr and the<br /> msg_addr may be changed while the vector is masked.<br /> <br /> [bhelgaas: commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: kalmia: validate USB endpoints<br /> <br /> The kalmia driver should validate that the device it is probing has the<br /> proper number and types of USB endpoints it is expecting before it binds<br /> to it. If a malicious device were to not have the same urbs the driver<br /> will crash later on when it blindly accesses these endpoints.