Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: prevent infinite loops caused by the next valid being the same<br /> <br /> When processing valid within the range [valid : pos), if valid cannot<br /> be retrieved correctly, for example, if the retrieved valid value is<br /> always the same, this can trigger a potential infinite loop, similar<br /> to the hung problem reported by syzbot [1].<br /> <br /> Adding a check for the valid value within the loop body, and terminating<br /> the loop and returning -EINVAL if the value is the same as the current<br /> value, can prevent this.<br /> <br /> [1]<br /> INFO: task syz.4.21:6056 blocked for more than 143 seconds.<br /> Call Trace:<br /> rwbase_write_lock+0x14f/0x750 kernel/locking/rwbase_rt.c:244<br /> inode_lock include/linux/fs.h:1027 [inline]<br /> ntfs_file_write_iter+0xe6/0x870 fs/ntfs3/file.c:1284

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp i2c: initialise event handler read bytes<br /> <br /> Set a 0xff value for i2c reads of an mctp-i2c device. Otherwise reads<br /> will return "val" from the i2c bus driver. For i2c-aspeed and<br /> i2c-npcm7xx that is a stack uninitialised u8.<br /> <br /> Tested with "i2ctransfer -y 1 r10@0x34" where 0x34 is a mctp-i2c<br /> instance, now it returns all 0xff.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: caif: fix use-after-free in caif_serial ldisc_close()<br /> <br /> There is a use-after-free bug in caif_serial where handle_tx() may<br /> access ser-&gt;tty after the tty has been freed.<br /> <br /> The race condition occurs between ldisc_close() and packet transmission:<br /> <br /> CPU 0 (close) CPU 1 (xmit)<br /> ------------- ------------<br /> ldisc_close()<br /> tty_kref_put(ser-&gt;tty)<br /> [tty may be freed here]<br /> <br /> caif_xmit()<br /> handle_tx()<br /> tty = ser-&gt;tty // dangling ptr<br /> tty-&gt;ops-&gt;write() // UAF!<br /> schedule_work()<br /> ser_release()<br /> unregister_netdevice()<br /> <br /> The root cause is that tty_kref_put() is called in ldisc_close() while<br /> the network device is still active and can receive packets.<br /> <br /> Since ser and tty have a 1:1 binding relationship with consistent<br /> lifecycles (ser is allocated in ldisc_open and freed in ser_release<br /> via unregister_netdevice, and each ser binds exactly one tty), we can<br /> safely defer the tty reference release to ser_release() where the<br /> network device is unregistered.<br /> <br /> Fix this by moving tty_kref_put() from ldisc_close() to ser_release(),<br /> after unregister_netdevice(). This ensures the tty reference is held<br /> as long as the network device exists, preventing the UAF.<br /> <br /> Note: We save ser-&gt;tty before unregister_netdevice() because ser is<br /> embedded in netdev&amp;#39;s private data and will be freed along with netdev<br /> (needs_free_netdev = true).<br /> <br /> How to reproduce: Add mdelay(500) at the beginning of ldisc_close()<br /> to widen the race window, then run the reproducer program [1].<br /> <br /> Note: There is a separate deadloop issue in handle_tx() when using<br /> PORT_UNKNOWN serial ports (e.g., /dev/ttyS3 in QEMU without proper<br /> serial backend). This deadloop exists even without this patch,<br /> and is likely caused by inconsistency between uart_write_room() and<br /> uart_write() in serial core. It has been addressed in a separate<br /> patch [2].<br /> <br /> KASAN report:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in handle_tx+0x5d1/0x620<br /> Read of size 1 at addr ffff8881131e1490 by task caif_uaf_trigge/9929<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x10e/0x1f0<br /> print_report+0xd0/0x630<br /> kasan_report+0xe4/0x120<br /> handle_tx+0x5d1/0x620<br /> dev_hard_start_xmit+0x9d/0x6c0<br /> __dev_queue_xmit+0x6e2/0x4410<br /> packet_xmit+0x243/0x360<br /> packet_sendmsg+0x26cf/0x5500<br /> __sys_sendto+0x4a3/0x520<br /> __x64_sys_sendto+0xe0/0x1c0<br /> do_syscall_64+0xc9/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f615df2c0d7<br /> <br /> Allocated by task 9930:<br /> <br /> Freed by task 64:<br /> <br /> Last potentially related work creation:<br /> <br /> The buggy address belongs to the object at ffff8881131e1000<br /> which belongs to the cache kmalloc-cg-2k of size 2048<br /> The buggy address is located 1168 bytes inside of<br /> freed 2048-byte region [ffff8881131e1000, ffff8881131e1800)<br /> <br /> The buggy address belongs to the physical page:<br /> page_owner tracks the page as allocated<br /> page last free pid 9778 tgid 9778 stack trace:<br /> <br /> Memory state around the buggy address:<br /> ffff8881131e1380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8881131e1400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> &gt;ffff8881131e1480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff8881131e1500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff8881131e1580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================<br /> [1]: https://gist.github.com/mrpre/f683f244544f7b11e7fa87df9e6c2eeb<br /> [2]: https://lore.kernel.org/linux-serial/20260204074327.226165-1-jiayuan.chen@linux.dev/T/#u

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation<br /> <br /> Ulrich reports a regression with nfqueue:<br /> <br /> If an application did not set the &amp;#39;F_GSO&amp;#39; capability flag and a gso<br /> packet with an unconfirmed nf_conn entry is received all packets are<br /> now dropped instead of queued, because the check happens after<br /> skb_gso_segment(). In that case, we did have exclusive ownership<br /> of the skb and its associated conntrack entry. The elevated use<br /> count is due to skb_clone happening via skb_gso_segment().<br /> <br /> Move the check so that its peformed vs. the aggregated packet.<br /> <br /> Then, annotate the individual segments except the first one so we<br /> can do a 2nd check at reinject time.<br /> <br /> For the normal case, where userspace does in-order reinjects, this avoids<br /> packet drops: first reinjected segment continues traversal and confirms<br /> entry, remaining segments observe the confirmed entry.<br /> <br /> While at it, simplify nf_ct_drop_unconfirmed(): We only care about<br /> unconfirmed entries with a refcnt &gt; 1, there is no need to special-case<br /> dying entries.<br /> <br /> This only happens with UDP. With TCP, the only unconfirmed packet will<br /> be the TCP SYN, those aren&amp;#39;t aggregated by GRO.<br /> <br /> Next patch adds a udpgro test case to cover this scenario.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conncount: increase the connection clean up limit to 64<br /> <br /> After the optimization to only perform one GC per jiffy, a new problem<br /> was introduced. If more than 8 new connections are tracked per jiffy the<br /> list won&amp;#39;t be cleaned up fast enough possibly reaching the limit<br /> wrongly.<br /> <br /> In order to prevent this issue, only skip the GC if it was already<br /> triggered during the same jiffy and the increment is lower than the<br /> clean up limit. In addition, increase the clean up limit to 64<br /> connections to avoid triggering GC too often and do more effective GCs.<br /> <br /> This has been tested using a HTTP server and several<br /> performance tools while having nft_connlimit/xt_connlimit or OVS limit<br /> configured.<br /> <br /> Output of slowhttptest + OVS limit at 52000 connections:<br /> <br /> slow HTTP test status on 340th second:<br /> initializing: 0<br /> pending: 432<br /> connected: 51998<br /> error: 0<br /> closed: 0<br /> service available: YES

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Fix slab-use-after-free in qd_put<br /> <br /> Commit a475c5dd16e5 ("gfs2: Free quota data objects synchronously")<br /> started freeing quota data objects during filesystem shutdown instead of<br /> putting them back onto the LRU list, but it failed to remove these<br /> objects from the LRU list, causing LRU list corruption. This caused<br /> use-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access<br /> already-freed objects on the LRU list.<br /> <br /> Fix this by removing qd objects from the LRU list before freeing them in<br /> qd_put().<br /> <br /> Initial fix from Deepanshu Kartikey .

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Flush cache for PASID table before using it<br /> <br /> When writing the address of a freshly allocated zero-initialized PASID<br /> table to a PASID directory entry, do that after the CPU cache flush for<br /> this PASID table, not before it, to avoid the time window when this<br /> PASID table may be already used by non-coherent IOMMU hardware while<br /> its contents in RAM is still some random old data, not zero-initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi: Fix reservation of unaccepted memory table<br /> <br /> The reserve_unaccepted() function incorrectly calculates the size of the<br /> memblock reservation for the unaccepted memory table. It aligns the<br /> size of the table, but fails to account for cases where the table&amp;#39;s<br /> starting physical address (efi.unaccepted) is not page-aligned.<br /> <br /> If the table starts at an offset within a page and its end crosses into<br /> a subsequent page that the aligned size does not cover, the end of the<br /> table will not be reserved. This can lead to the table being overwritten<br /> or inaccessible, causing a kernel panic in accept_memory().<br /> <br /> This issue was observed when starting Intel TDX VMs with specific memory<br /> sizes (e.g., &gt; 64GB).<br /> <br /> Fix this by calculating the end address first (including the unaligned<br /> start) and then aligning it up, ensuring the entire range is covered<br /> by the reservation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Use kvfree instead of kfree in amdgpu_gmc_get_nps_memranges()<br /> <br /> amdgpu_discovery_get_nps_info() internally allocates memory for ranges<br /> using kvcalloc(), which may use vmalloc() for large allocation. Using<br /> kfree() to release vmalloc memory will lead to a memory corruption.<br /> <br /> Use kvfree() to safely handle both kmalloc and vmalloc allocations.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: inside-secure/eip93 - unregister only available algorithm<br /> <br /> EIP93 has an options register. This register indicates which crypto<br /> algorithms are implemented in silicon. Supported algorithms are<br /> registered on this basis. Unregister algorithms on the same basis.<br /> Currently, all algorithms are unregistered, even those not supported<br /> by HW. This results in panic on platforms that don&amp;#39;t have all options<br /> implemented in silicon.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-scsi: avoid Non-NCQ command starvation<br /> <br /> When a non-NCQ command is issued while NCQ commands are being executed,<br /> ata_scsi_qc_issue() indicates to the SCSI layer that the command issuing<br /> should be deferred by returning SCSI_MLQUEUE_XXX_BUSY. This command<br /> deferring is correct and as mandated by the ACS specifications since<br /> NCQ and non-NCQ commands cannot be mixed.<br /> <br /> However, in the case of a host adapter using multiple submission queues,<br /> when the target device is under a constant load of NCQ commands, there<br /> are no guarantees that requeueing the non-NCQ command will be executed<br /> later and it may be deferred again repeatedly as other submission queues<br /> can constantly issue NCQ commands from different CPUs ahead of the<br /> non-NCQ command. This can lead to very long delays for the execution of<br /> non-NCQ commands, and even complete starvation for these commands in the<br /> worst case scenario.<br /> <br /> Since the block layer and the SCSI layer do not distinguish between<br /> queueable (NCQ) and non queueable (non-NCQ) commands, libata-scsi SAT<br /> implementation must ensure forward progress for non-NCQ commands in the<br /> presence of NCQ command traffic. This is similar to what SAS HBAs with a<br /> hardware/firmware based SAT implementation do.<br /> <br /> Implement such forward progress guarantee by limiting requeueing of<br /> non-NCQ commands from ata_scsi_qc_issue(): when a non-NCQ command is<br /> received and NCQ commands are in-flight, do not force a requeue of the<br /> non-NCQ command by returning SCSI_MLQUEUE_XXX_BUSY and instead return 0<br /> to indicate that the command was accepted but hold on to the qc using<br /> the new deferred_qc field of struct ata_port.<br /> <br /> This deferred qc will be issued using the work item deferred_qc_work<br /> running the function ata_scsi_deferred_qc_work() once all in-flight<br /> commands complete, which is checked with the port qc_defer() callback<br /> return value indicating that no further delay is necessary. This check<br /> is done using the helper function ata_scsi_schedule_deferred_qc() which<br /> is called from ata_scsi_qc_complete(). This thus excludes this mechanism<br /> from all internal non-NCQ commands issued by ATA EH.<br /> <br /> When a port deferred_qc is non NULL, that is, the port has a command<br /> waiting for the device queue to drain, the issuing of all incoming<br /> commands (both NCQ and non-NCQ) is deferred using the regular busy<br /> mechanism. This simplifies the code and also avoids potential denial of<br /> service problems if a user issues too many non-NCQ commands.<br /> <br /> Finally, whenever ata EH is scheduled, regardless of the reason, a<br /> deferred qc is always requeued so that it can be retried once EH<br /> completes. This is done by calling the function<br /> ata_scsi_requeue_deferred_qc() from ata_eh_set_pending(). This avoids<br /> the need for any special processing for the deferred qc in case of NCQ<br /> error, link or device reset, or device timeout.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: csiostor: Fix dereference of null pointer rn<br /> <br /> The error exit path when rn is NULL ends up deferencing the null pointer rn<br /> via the use of the macro CSIO_INC_STATS. Fix this by adding a new error<br /> return path label after the use of the macro to avoid the deference.