Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: wm97xx: Fix NULL pointer dereference in power_supply_changed()<br /> <br /> In `probe()`, `request_irq()` is called before allocating/registering a<br /> `power_supply` handle. If an interrupt is fired between the call to<br /> `request_irq()` and `power_supply_register()`, the `power_supply` handle<br /> will be used uninitialized in `power_supply_changed()` in<br /> `wm97xx_bat_update()` (triggered from the interrupt handler). This will<br /> lead to a `NULL` pointer dereference since<br /> <br /> Fix this racy `NULL` pointer dereference by making sure the IRQ is<br /> requested _after_ the registration of the `power_supply` handle. Since<br /> the IRQ is the last thing requests in the `probe()` now, remove the<br /> error path for freeing it. Instead add one for unregistering the<br /> `power_supply` handle when IRQ request fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: auth_gss: fix memory leaks in XDR decoding error paths<br /> <br /> The gssx_dec_ctx(), gssx_dec_status(), and gssx_dec_name()<br /> functions allocate memory via gssx_dec_buffer(), which calls<br /> kmemdup(). When a subsequent decode operation fails, these<br /> functions return immediately without freeing previously<br /> allocated buffers, causing memory leaks.<br /> <br /> The leak in gssx_dec_ctx() is particularly relevant because<br /> the caller (gssp_accept_sec_context_upcall) initializes several<br /> buffer length fields to non-zero values, resulting in memory<br /> allocation:<br /> <br /> struct gssx_ctx rctxh = {<br /> .exported_context_token.len = GSSX_max_output_handle_sz,<br /> .mech.len = GSS_OID_MAX_LEN,<br /> .src_name.display_name.len = GSSX_max_princ_sz,<br /> .targ_name.display_name.len = GSSX_max_princ_sz<br /> };<br /> <br /> If, for example, gssx_dec_name() succeeds for src_name but<br /> fails for targ_name, the memory allocated for<br /> exported_context_token, mech, and src_name.display_name<br /> remains unreferenced and cannot be reclaimed.<br /> <br /> Add error handling with goto-based cleanup to free any<br /> previously allocated buffers before returning an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: st33zp24: Fix missing cleanup on get_burstcount() error<br /> <br /> get_burstcount() can return -EBUSY on timeout. When this happens,<br /> st33zp24_send() returns directly without releasing the locality<br /> acquired earlier.<br /> <br /> Use goto out_err to ensure proper cleanup when get_burstcount() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: smartpqi: Fix memory leak in pqi_report_phys_luns()<br /> <br /> pqi_report_phys_luns() fails to release the rpl_list buffer when<br /> encountering an unsupported data format or when the allocation for<br /> rpl_16byte_wwid_list fails. These early returns bypass the cleanup logic,<br /> leading to memory leaks.<br /> <br /> Consolidate the error handling by adding an out_free_rpl_list label and use<br /> goto statements to ensure rpl_list is consistently freed on failure.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool and<br /> code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_set_rbtree: check for partial overlaps in anonymous sets<br /> <br /> Userspace provides an optimized representation in case intervals are<br /> adjacent, where the end element is omitted.<br /> <br /> The existing partial overlap detection logic skips anonymous set checks<br /> on start elements for this reason.<br /> <br /> However, it is possible to add intervals that overlap to this anonymous<br /> where two start elements with the same, eg. A-B, A-C where C

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: freescale: imx8qm-hsio: fix NULL pointer dereference<br /> <br /> During the probe the refclk_pad pointer is set to NULL if the<br /> &amp;#39;fsl,refclk-pad-mode&amp;#39; property is not defined in the devicetree node. But<br /> in imx_hsio_configure_clk_pad() this pointer is unconditionally used which<br /> could result in a NULL pointer dereference. So check the pointer before to<br /> use it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: dw: Fix memory leak in dw_i3c_master_i2c_xfers()<br /> <br /> The dw_i3c_master_i2c_xfers() function allocates memory for the xfer<br /> structure using dw_i3c_master_alloc_xfer(). If pm_runtime_resume_and_get()<br /> fails, the function returns without freeing the allocated xfer, resulting<br /> in a memory leak.<br /> <br /> Add a dw_i3c_master_free_xfer() call to the error path to ensure the<br /> allocated memory is properly freed.<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 /> 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