Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (coretemp) Simplify platform device handling<br /> <br /> Coretemp&amp;#39;s platform driver is unconventional. All the real work is done<br /> globally by the initcall and CPU hotplug notifiers, while the "driver"<br /> effectively just wraps an allocation and the registration of the hwmon<br /> interface in a long-winded round-trip through the driver core. The whole<br /> logic of dynamically creating and destroying platform devices to bring<br /> the interfaces up and down is error prone, since it assumes<br /> platform_device_add() will synchronously bind the driver and set drvdata<br /> before it returns, thus results in a NULL dereference if drivers_autoprobe<br /> is turned off for the platform bus. Furthermore, the unusual approach of<br /> doing that from within a CPU hotplug notifier, already commented in the<br /> code that it deadlocks suspend, also causes lockdep issues for other<br /> drivers or subsystems which may want to legitimately register a CPU<br /> hotplug notifier from a platform bus notifier.<br /> <br /> All of these issues can be solved by ripping this unusual behaviour out<br /> completely, simply tying the platform devices to the lifetime of the<br /> module itself, and directly managing the hwmon interfaces from the<br /> hotplug notifiers. There is a slight user-visible change in that<br /> /sys/bus/platform/drivers/coretemp will no longer appear, and<br /> /sys/devices/platform/coretemp.n will remain present if package n is<br /> hotplugged off, but hwmon users should really only be looking for the<br /> presence of the hwmon interfaces, whose behaviour remains unchanged.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi_si: fix a memleak in try_smi_init()<br /> <br /> Kmemleak reported the following leak info in try_smi_init():<br /> <br /> unreferenced object 0xffff00018ecf9400 (size 1024):<br /> comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s)<br /> backtrace:<br /> [] __kmalloc+0x4b8/0x7b0<br /> [] try_smi_init+0x148/0x5dc [ipmi_si]<br /> [] 0xffff800081b10148<br /> [] do_one_initcall+0x64/0x2a4<br /> [] do_init_module+0x50/0x300<br /> [] load_module+0x7a8/0x9e0<br /> [] __se_sys_init_module+0x104/0x180<br /> [] __arm64_sys_init_module+0x24/0x30<br /> [] el0_svc_common.constprop.0+0x94/0x250<br /> [] do_el0_svc+0x48/0xe0<br /> [] el0_svc+0x24/0x3c<br /> [] el0_sync_handler+0x160/0x164<br /> [] el0_sync+0x160/0x180<br /> <br /> The problem was that when an error occurred before handlers registration<br /> and after allocating `new_smi-&gt;si_sm`, the variable wouldn&amp;#39;t be freed in<br /> the error handling afterwards since `shutdown_smi()` hadn&amp;#39;t been<br /> registered yet. Fix it by adding a `kfree()` in the error handling path<br /> in `try_smi_init()`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip: Fix refcount leak in platform_irqchip_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: Revert "scsi: core: Do not increase scsi_device&amp;#39;s iorequest_cnt if dispatch failed"<br /> <br /> The "atomic_inc(&amp;cmd-&gt;device-&gt;iorequest_cnt)" in scsi_queue_rq() would<br /> cause kernel panic because cmd-&gt;device may be freed after returning from<br /> scsi_dispatch_cmd().<br /> <br /> This reverts commit cfee29ffb45b1c9798011b19d454637d1b0fe87d.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread()<br /> <br /> The finalization of nilfs_segctor_thread() can race with<br /> nilfs_segctor_kill_thread() which terminates that thread, potentially<br /> causing a use-after-free BUG as KASAN detected.<br /> <br /> At the end of nilfs_segctor_thread(), it assigns NULL to "sc_task" member<br /> of "struct nilfs_sc_info" to indicate the thread has finished, and then<br /> notifies nilfs_segctor_kill_thread() of this using waitqueue<br /> "sc_wait_task" on the struct nilfs_sc_info.<br /> <br /> However, here, immediately after the NULL assignment to "sc_task", it is<br /> possible that nilfs_segctor_kill_thread() will detect it and return to<br /> continue the deallocation, freeing the nilfs_sc_info structure before the<br /> thread does the notification.<br /> <br /> This fixes the issue by protecting the NULL assignment to "sc_task" and<br /> its notification, with spinlock "sc_state_lock" of the struct<br /> nilfs_sc_info. Since nilfs_segctor_kill_thread() does a final check to<br /> see if "sc_task" is NULL with "sc_state_lock" locked, this can eliminate<br /> the race.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ymfpci: Fix BUG_ON in probe function<br /> <br /> The snd_dma_buffer.bytes field now contains the aligned size, which this<br /> snd_BUG_ON() did not account for, resulting in the following:<br /> <br /> [ 9.625915] ------------[ cut here ]------------<br /> [ 9.633440] WARNING: CPU: 0 PID: 126 at sound/pci/ymfpci/ymfpci_main.c:2168 snd_ymfpci_create+0x681/0x698 [snd_ymfpci]<br /> [ 9.648926] Modules linked in: snd_ymfpci(+) snd_intel_dspcfg kvm(+) snd_intel_sdw_acpi snd_ac97_codec snd_mpu401_uart snd_opl3_lib irqbypass snd_hda_codec gameport snd_rawmidi crct10dif_pclmul crc32_pclmul cfg80211 snd_hda_core polyval_clmulni polyval_generic gf128mul snd_seq_device ghash_clmulni_intel snd_hwdep ac97_bus sha512_ssse3 rfkill snd_pcm aesni_intel tg3 snd_timer crypto_simd snd mxm_wmi libphy cryptd k10temp fam15h_power pcspkr soundcore sp5100_tco wmi acpi_cpufreq mac_hid dm_multipath sg loop fuse dm_mod bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi firewire_ohci crc32c_intel firewire_core xhci_pci crc_itu_t pata_via xhci_pci_renesas floppy<br /> [ 9.711849] CPU: 0 PID: 126 Comm: kworker/0:2 Not tainted 6.1.21-1-lts #1 08d2e5ece03136efa7c6aeea9a9c40916b1bd8da<br /> [ 9.722200] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./990FX Extreme4, BIOS P2.70 06/05/2014<br /> [ 9.732204] Workqueue: events work_for_cpu_fn<br /> [ 9.736580] RIP: 0010:snd_ymfpci_create+0x681/0x698 [snd_ymfpci]<br /> [ 9.742594] Code: 8c c0 4c 89 e2 48 89 df 48 c7 c6 92 c6 8c c0 e8 15 d0 e9 ff 48 83 c4 08 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d3 7a 33 e3 0b e9 cb fd ff ff 41 bd fb ff ff ff eb db 41 bd f4 ff ff ff eb<br /> [ 9.761358] RSP: 0018:ffffab64804e7da0 EFLAGS: 00010287<br /> [ 9.766594] RAX: ffff8fa2df06c400 RBX: ffff8fa3073a8000 RCX: ffff8fa303fbc4a8<br /> [ 9.773734] RDX: ffff8fa2df06d000 RSI: 0000000000000010 RDI: 0000000000000020<br /> [ 9.780876] RBP: ffff8fa300b5d0d0 R08: ffff8fa3073a8e50 R09: 00000000df06bf00<br /> [ 9.788018] R10: ffff8fa2df06bf00 R11: 00000000df068200 R12: ffff8fa3073a8918<br /> [ 9.795159] R13: 0000000000000000 R14: 0000000000000080 R15: ffff8fa2df068200<br /> [ 9.802317] FS: 0000000000000000(0000) GS:ffff8fa9fec00000(0000) knlGS:0000000000000000<br /> [ 9.810414] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 9.816158] CR2: 000055febaf66500 CR3: 0000000101a2e000 CR4: 00000000000406f0<br /> [ 9.823301] Call Trace:<br /> [ 9.825747] <br /> [ 9.827889] snd_card_ymfpci_probe+0x194/0x950 [snd_ymfpci b78a5fe64b5663a6390a909c67808567e3e73615]<br /> [ 9.837030] ? finish_task_switch.isra.0+0x90/0x2d0<br /> [ 9.841918] local_pci_probe+0x45/0x80<br /> [ 9.845680] work_for_cpu_fn+0x1a/0x30<br /> [ 9.849431] process_one_work+0x1c7/0x380<br /> [ 9.853464] worker_thread+0x1af/0x390<br /> [ 9.857225] ? rescuer_thread+0x3b0/0x3b0<br /> [ 9.861254] kthread+0xde/0x110<br /> [ 9.864414] ? kthread_complete_and_exit+0x20/0x20<br /> [ 9.869210] ret_from_fork+0x22/0x30<br /> [ 9.872792] <br /> [ 9.874985] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: clean up potential nfsd_file refcount leaks in COPY codepath<br /> <br /> There are two different flavors of the nfsd4_copy struct. One is<br /> embedded in the compound and is used directly in synchronous copies. The<br /> other is dynamically allocated, refcounted and tracked in the client<br /> struture. For the embedded one, the cleanup just involves releasing any<br /> nfsd_files held on its behalf. For the async one, the cleanup is a bit<br /> more involved, and we need to dequeue it from lists, unhash it, etc.<br /> <br /> There is at least one potential refcount leak in this code now. If the<br /> kthread_create call fails, then both the src and dst nfsd_files in the<br /> original nfsd4_copy object are leaked.<br /> <br /> The cleanup in this codepath is also sort of weird. In the async copy<br /> case, we&amp;#39;ll have up to four nfsd_file references (src and dst for both<br /> flavors of copy structure). They are both put at the end of<br /> nfsd4_do_async_copy, even though the ones held on behalf of the embedded<br /> one outlive that structure.<br /> <br /> Change it so that we always clean up the nfsd_file refs held by the<br /> embedded copy structure before nfsd4_copy returns. Rework<br /> cleanup_async_copy to handle both inter and intra copies. Eliminate<br /> nfsd4_cleanup_intra_ssc since it now becomes a no-op.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: amd: display: Fix memory leakage<br /> <br /> This commit fixes memory leakage in dc_construct_ctx() function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm integrity: call kmem_cache_destroy() in dm_integrity_init() error path<br /> <br /> Otherwise the journal_io_cache will leak if dm_register_target() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Avoid fcport pointer dereference<br /> <br /> Klocwork reported warning of NULL pointer may be dereferenced. The routine<br /> exits when sa_ctl is NULL and fcport is allocated after the exit call thus<br /> causing NULL fcport pointer to dereference at the time of exit.<br /> <br /> To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix memory leak in WMI firmware stats<br /> <br /> Memory allocated for firmware pdev, vdev and beacon statistics<br /> are not released during rmmod.<br /> <br /> Fix it by calling ath11k_fw_stats_free() function before hardware<br /> unregister.<br /> <br /> While at it, avoid calling ath11k_fw_stats_free() while processing<br /> the firmware stats received in the WMI event because the local list<br /> is getting spliced and reinitialised and hence there are no elements<br /> in the list after splicing.<br /> <br /> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: do not assume skb mac_header is set<br /> <br /> Drivers must not assume in their ndo_start_xmit() that<br /> skbs have their mac_header set. skb-&gt;data is all what is needed.<br /> <br /> bonding seems to be one of the last offender as caught by syzbot:<br /> <br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470<br /> Modules linked in:<br /> CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023<br /> RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]<br /> RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]<br /> RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]<br /> RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]<br /> RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]<br /> RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]<br /> RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470<br /> Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe<br /> RSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283<br /> RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000<br /> RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6<br /> RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584<br /> R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e<br /> R13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76<br /> FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> [] netdev_start_xmit include/linux/netdevice.h:4925 [inline]<br /> [] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380<br /> [] dev_direct_xmit include/linux/netdevice.h:3043 [inline]<br /> [] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284<br /> [] packet_snd net/packet/af_packet.c:3112 [inline]<br /> [] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143<br /> [] sock_sendmsg_nosec net/socket.c:716 [inline]<br /> [] sock_sendmsg net/socket.c:736 [inline]<br /> [] __sys_sendto+0x472/0x5f0 net/socket.c:2139<br /> [] __do_sys_sendto net/socket.c:2151 [inline]<br /> [] __se_sys_sendto net/socket.c:2147 [inline]<br /> [] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd