Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix nfsd4_deleg_getattr_conflict in presence of third party lease<br /> <br /> It is not safe to dereference fl-&gt;c.flc_owner without first confirming<br /> fl-&gt;fl_lmops is the expected manager. nfsd4_deleg_getattr_conflict()<br /> tests fl_lmops but largely ignores the result and assumes that flc_owner<br /> is an nfs4_delegation anyway. This is wrong.<br /> <br /> With this patch we restore the "!= &amp;nfsd_lease_mng_ops" case to behave<br /> as it did before the change mentioned below. This is the same as the<br /> current code, but without any reference to a possible delegation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Move unregister out of atomic section<br /> <br /> Commit &amp;#39;9329933699b3 ("soc: qcom: pmic_glink: Make client-lock<br /> non-sleeping")&amp;#39; moved the pmic_glink client list under a spinlock, as it<br /> is accessed by the rpmsg/glink callback, which in turn is invoked from<br /> IRQ context.<br /> <br /> This means that ucsi_unregister() is now called from atomic context,<br /> which isn&amp;#39;t feasible as it&amp;#39;s expecting a sleepable context. An effort is<br /> under way to get GLINK to invoke its callbacks in a sleepable context,<br /> but until then lets schedule the unregistration.<br /> <br /> A side effect of this is that ucsi_unregister() can now happen<br /> after the remote processor, and thereby the communication link with it, is<br /> gone. pmic_glink_send() is amended with a check to avoid the resulting NULL<br /> pointer dereference.<br /> This does however result in the user being informed about this error by<br /> the following entry in the kernel log:<br /> <br /> ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: single: fix potential NULL dereference in pcs_get_function()<br /> <br /> pinmux_generic_get_function() can return NULL and the pointer &amp;#39;function&amp;#39;<br /> was dereferenced without checking against NULL. Add checking of pointer<br /> &amp;#39;function&amp;#39; in pcs_get_function().<br /> <br /> Found by code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()<br /> <br /> This happens when called from SMB2_read() while using rdma<br /> and reaching the rdma_readwrite_threshold.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix a use-after-free when hitting errors inside btrfs_submit_chunk()<br /> <br /> [BUG]<br /> There is an internal report that KASAN is reporting use-after-free, with<br /> the following backtrace:<br /> <br /> BUG: KASAN: slab-use-after-free in btrfs_check_read_bio+0xa68/0xb70 [btrfs]<br /> Read of size 4 at addr ffff8881117cec28 by task kworker/u16:2/45<br /> CPU: 1 UID: 0 PID: 45 Comm: kworker/u16:2 Not tainted 6.11.0-rc2-next-20240805-default+ #76<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]<br /> Call Trace:<br /> dump_stack_lvl+0x61/0x80<br /> print_address_description.constprop.0+0x5e/0x2f0<br /> print_report+0x118/0x216<br /> kasan_report+0x11d/0x1f0<br /> btrfs_check_read_bio+0xa68/0xb70 [btrfs]<br /> process_one_work+0xce0/0x12a0<br /> worker_thread+0x717/0x1250<br /> kthread+0x2e3/0x3c0<br /> ret_from_fork+0x2d/0x70<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Allocated by task 20917:<br /> kasan_save_stack+0x37/0x60<br /> kasan_save_track+0x10/0x30<br /> __kasan_slab_alloc+0x7d/0x80<br /> kmem_cache_alloc_noprof+0x16e/0x3e0<br /> mempool_alloc_noprof+0x12e/0x310<br /> bio_alloc_bioset+0x3f0/0x7a0<br /> btrfs_bio_alloc+0x2e/0x50 [btrfs]<br /> submit_extent_page+0x4d1/0xdb0 [btrfs]<br /> btrfs_do_readpage+0x8b4/0x12a0 [btrfs]<br /> btrfs_readahead+0x29a/0x430 [btrfs]<br /> read_pages+0x1a7/0xc60<br /> page_cache_ra_unbounded+0x2ad/0x560<br /> filemap_get_pages+0x629/0xa20<br /> filemap_read+0x335/0xbf0<br /> vfs_read+0x790/0xcb0<br /> ksys_read+0xfd/0x1d0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 20917:<br /> kasan_save_stack+0x37/0x60<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x37/0x50<br /> __kasan_slab_free+0x4b/0x60<br /> kmem_cache_free+0x214/0x5d0<br /> bio_free+0xed/0x180<br /> end_bbio_data_read+0x1cc/0x580 [btrfs]<br /> btrfs_submit_chunk+0x98d/0x1880 [btrfs]<br /> btrfs_submit_bio+0x33/0x70 [btrfs]<br /> submit_one_bio+0xd4/0x130 [btrfs]<br /> submit_extent_page+0x3ea/0xdb0 [btrfs]<br /> btrfs_do_readpage+0x8b4/0x12a0 [btrfs]<br /> btrfs_readahead+0x29a/0x430 [btrfs]<br /> read_pages+0x1a7/0xc60<br /> page_cache_ra_unbounded+0x2ad/0x560<br /> filemap_get_pages+0x629/0xa20<br /> filemap_read+0x335/0xbf0<br /> vfs_read+0x790/0xcb0<br /> ksys_read+0xfd/0x1d0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [CAUSE]<br /> Although I cannot reproduce the error, the report itself is good enough<br /> to pin down the cause.<br /> <br /> The call trace is the regular endio workqueue context, but the<br /> free-by-task trace is showing that during btrfs_submit_chunk() we<br /> already hit a critical error, and is calling btrfs_bio_end_io() to error<br /> out. And the original endio function called bio_put() to free the whole<br /> bio.<br /> <br /> This means a double freeing thus causing use-after-free, e.g.:<br /> <br /> 1. Enter btrfs_submit_bio() with a read bio<br /> The read bio length is 128K, crossing two 64K stripes.<br /> <br /> 2. The first run of btrfs_submit_chunk()<br /> <br /> 2.1 Call btrfs_map_block(), which returns 64K<br /> 2.2 Call btrfs_split_bio()<br /> Now there are two bios, one referring to the first 64K, the other<br /> referring to the second 64K.<br /> 2.3 The first half is submitted.<br /> <br /> 3. The second run of btrfs_submit_chunk()<br /> <br /> 3.1 Call btrfs_map_block(), which by somehow failed<br /> Now we call btrfs_bio_end_io() to handle the error<br /> <br /> 3.2 btrfs_bio_end_io() calls the original endio function<br /> Which is end_bbio_data_read(), and it calls bio_put() for the<br /> original bio.<br /> <br /> Now the original bio is freed.<br /> <br /> 4. The submitted first 64K bio finished<br /> Now we call into btrfs_check_read_bio() and tries to advance the bio<br /> iter.<br /> But since the original bio (thus its iter) is already freed, we<br /> trigger the above use-after free.<br /> <br /> And even if the memory is not poisoned/corrupted, we will later call<br /> the original endio function, causing a double freeing.<br /> <br /> [FIX]<br /> Instead of calling btrfs_bio_end_io(), call btrfs_orig_bbio_end_io(),<br /> which has the extra check on split bios and do the pr<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: core: Prevent USB core invalid event buffer address access<br /> <br /> This commit addresses an issue where the USB core could access an<br /> invalid event buffer address during runtime suspend, potentially causing<br /> SMMU faults and other memory issues in Exynos platforms. The problem<br /> arises from the following sequence.<br /> 1. In dwc3_gadget_suspend, there is a chance of a timeout when<br /> moving the USB core to the halt state after clearing the<br /> run/stop bit by software.<br /> 2. In dwc3_core_exit, the event buffer is cleared regardless of<br /> the USB core&amp;#39;s status, which may lead to an SMMU faults and<br /> other memory issues. if the USB core tries to access the event<br /> buffer address.<br /> <br /> To prevent this hardware quirk on Exynos platforms, this commit ensures<br /> that the event buffer address is not cleared by software when the USB<br /> core is active during runtime suspend by checking its status before<br /> clearing the buffer address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: pn533: Add poll mod list filling check<br /> <br /> In case of im_protocols value is 1 and tm_protocols value is 0 this<br /> combination successfully passes the check<br /> &amp;#39;if (!im_protocols &amp;&amp; !tm_protocols)&amp;#39; in the nfc_start_poll().<br /> But then after pn533_poll_create_mod_list() call in pn533_start_poll()<br /> poll mod list will remain empty and dev-&gt;poll_mod_count will remain 0<br /> which lead to division by zero.<br /> <br /> Normally no im protocol has value 1 in the mask, so this combination is<br /> not expected by driver. But these protocol values actually come from<br /> userspace via Netlink interface (NFC_CMD_START_POLL operation). So a<br /> broken or malicious program may pass a message containing a "bad"<br /> combination of protocol parameter values so that dev-&gt;poll_mod_count<br /> is not incremented inside pn533_poll_create_mod_list(), thus leading<br /> to division by zero.<br /> Call trace looks like:<br /> nfc_genl_start_poll()<br /> nfc_start_poll()<br /> -&gt;start_poll()<br /> pn533_start_poll()<br /> <br /> Add poll mod list filling check.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: change ipsec_lock from spin lock to mutex<br /> <br /> In the cited commit, bond-&gt;ipsec_lock is added to protect ipsec_list,<br /> hence xdo_dev_state_add and xdo_dev_state_delete are called inside<br /> this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,<br /> "scheduling while atomic" will be triggered when changing bond&amp;#39;s<br /> active slave.<br /> <br /> [ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200<br /> [ 101.055726] Modules linked in:<br /> [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1<br /> [ 101.058760] Hardware name:<br /> [ 101.059434] Call Trace:<br /> [ 101.059436] <br /> [ 101.060873] dump_stack_lvl+0x51/0x60<br /> [ 101.061275] __schedule_bug+0x4e/0x60<br /> [ 101.061682] __schedule+0x612/0x7c0<br /> [ 101.062078] ? __mod_timer+0x25c/0x370<br /> [ 101.062486] schedule+0x25/0xd0<br /> [ 101.062845] schedule_timeout+0x77/0xf0<br /> [ 101.063265] ? asm_common_interrupt+0x22/0x40<br /> [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10<br /> [ 101.064215] __wait_for_common+0x87/0x190<br /> [ 101.064648] ? usleep_range_state+0x90/0x90<br /> [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core]<br /> [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core]<br /> [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core]<br /> [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]<br /> [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding]<br /> [ 101.067738] ? kmalloc_trace+0x4d/0x350<br /> [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]<br /> [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]<br /> [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding]<br /> [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding]<br /> [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding]<br /> [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding]<br /> [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding]<br /> [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding]<br /> [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0<br /> [ 101.073033] vfs_write+0x2d8/0x400<br /> [ 101.073416] ? alloc_fd+0x48/0x180<br /> [ 101.073798] ksys_write+0x5f/0xe0<br /> [ 101.074175] do_syscall_64+0x52/0x110<br /> [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called<br /> from bond_change_active_slave, which requires holding the RTNL lock.<br /> And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state<br /> xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user<br /> context. So ipsec_lock doesn&amp;#39;t have to be spin lock, change it to<br /> mutex, and thus the above issue can be resolved.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: check device is present when getting link settings<br /> <br /> A sysfs reader can race with a device reset or removal, attempting to<br /> read device state when the device is not actually present. eg:<br /> <br /> [exception RIP: qed_get_current_link+17]<br /> #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]<br /> #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3<br /> #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4<br /> #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300<br /> #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c<br /> #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b<br /> #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3<br /> #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1<br /> #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f<br /> #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb<br /> <br /> crash&gt; struct net_device.state ffff9a9d21336000<br /> state = 5,<br /> <br /> state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).<br /> The device is not present, note lack of __LINK_STATE_PRESENT (0b10).<br /> <br /> This is the same sort of panic as observed in commit 4224cfd7fb65<br /> ("net-sysfs: add check for netdevice being present to speed_show").<br /> <br /> There are many other callers of __ethtool_get_link_ksettings() which<br /> don&amp;#39;t have a device presence check.<br /> <br /> Move this check into ethtool to protect all callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btnxpuart: Fix random crash seen while removing driver<br /> <br /> This fixes the random kernel crash seen while removing the driver, when<br /> running the load/unload test over multiple iterations.<br /> <br /> 1) modprobe btnxpuart<br /> 2) hciconfig hci0 reset<br /> 3) hciconfig (check hci0 interface up with valid BD address)<br /> 4) modprobe -r btnxpuart<br /> Repeat steps 1 to 4<br /> <br /> The ps_wakeup() call in btnxpuart_close() schedules the psdata-&gt;work(),<br /> which gets scheduled after module is removed, causing a kernel crash.<br /> <br /> This hidden issue got highlighted after enabling Power Save by default<br /> in 4183a7be7700 (Bluetooth: btnxpuart: Enable Power Save feature on<br /> startup)<br /> <br /> The new ps_cleanup() deasserts UART break immediately while closing<br /> serdev device, cancels any scheduled ps_work and destroys the ps_lock<br /> mutex.<br /> <br /> [ 85.884604] Unable to handle kernel paging request at virtual address ffffd4a61638f258<br /> [ 85.884624] Mem abort info:<br /> [ 85.884625] ESR = 0x0000000086000007<br /> [ 85.884628] EC = 0x21: IABT (current EL), IL = 32 bits<br /> [ 85.884633] SET = 0, FnV = 0<br /> [ 85.884636] EA = 0, S1PTW = 0<br /> [ 85.884638] FSC = 0x07: level 3 translation fault<br /> [ 85.884642] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041dd0000<br /> [ 85.884646] [ffffd4a61638f258] pgd=1000000095fff003, p4d=1000000095fff003, pud=100000004823d003, pmd=100000004823e003, pte=0000000000000000<br /> [ 85.884662] Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP<br /> [ 85.890932] Modules linked in: algif_hash algif_skcipher af_alg overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_spdif snd_soc_fsl_micfil snd_soc_fsl_sai snd_soc_fsl_utils gpio_ir_recv rc_core fuse [last unloaded: btnxpuart(O)]<br /> [ 85.927297] CPU: 1 PID: 67 Comm: kworker/1:3 Tainted: G O 6.1.36+g937b1be4345a #1<br /> [ 85.936176] Hardware name: FSL i.MX8MM EVK board (DT)<br /> [ 85.936182] Workqueue: events 0xffffd4a61638f380<br /> [ 85.936198] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 85.952817] pc : 0xffffd4a61638f258<br /> [ 85.952823] lr : 0xffffd4a61638f258<br /> [ 85.952827] sp : ffff8000084fbd70<br /> [ 85.952829] x29: ffff8000084fbd70 x28: 0000000000000000 x27: 0000000000000000<br /> [ 85.963112] x26: ffffd4a69133f000 x25: ffff4bf1c8540990 x24: ffff4bf215b87305<br /> [ 85.963119] x23: ffff4bf215b87300 x22: ffff4bf1c85409d0 x21: ffff4bf1c8540970<br /> [ 85.977382] x20: 0000000000000000 x19: ffff4bf1c8540880 x18: 0000000000000000<br /> [ 85.977391] x17: 0000000000000000 x16: 0000000000000133 x15: 0000ffffe2217090<br /> [ 85.977399] x14: 0000000000000001 x13: 0000000000000133 x12: 0000000000000139<br /> [ 85.977407] x11: 0000000000000001 x10: 0000000000000a60 x9 : ffff8000084fbc50<br /> [ 85.977417] x8 : ffff4bf215b7d000 x7 : ffff4bf215b83b40 x6 : 00000000000003e8<br /> [ 85.977424] x5 : 00000000410fd030 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 85.977432] x2 : 0000000000000000 x1 : ffff4bf1c4265880 x0 : 0000000000000000<br /> [ 85.977443] Call trace:<br /> [ 85.977446] 0xffffd4a61638f258<br /> [ 85.977451] 0xffffd4a61638f3e8<br /> [ 85.977455] process_one_work+0x1d4/0x330<br /> [ 85.977464] worker_thread+0x6c/0x430<br /> [ 85.977471] kthread+0x108/0x10c<br /> [ 85.977476] ret_from_fork+0x10/0x20<br /> [ 85.977488] Code: bad PC value<br /> [ 85.977491] ---[ end trace 0000000000000000 ]---<br /> <br /> Preset since v6.9.11

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pktgen: use cpus_read_lock() in pg_net_init()<br /> <br /> I have seen the WARN_ON(smp_processor_id() != cpu) firing<br /> in pktgen_thread_worker() during tests.<br /> <br /> We must use cpus_read_lock()/cpus_read_unlock()<br /> around the for_each_online_cpu(cpu) loop.<br /> <br /> While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: st: fix probed platform device ref count on probe error path<br /> <br /> The probe function never performs any paltform device allocation, thus<br /> error path "undo_platform_dev_alloc" is entirely bogus. It drops the<br /> reference count from the platform device being probed. If error path is<br /> triggered, this will lead to unbalanced device reference counts and<br /> premature release of device resources, thus possible use-after-free when<br /> releasing remaining devm-managed resources.