Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> octeontx2-pf: mcs: Fix NULL pointer dereferences<br /> <br /> When system is rebooted after creating macsec interface<br /> below NULL pointer dereference crashes occurred. This<br /> patch fixes those crashes by using correct order of teardown<br /> <br /> [ 3324.406942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 3324.415726] Mem abort info:<br /> [ 3324.418510] ESR = 0x96000006<br /> [ 3324.421557] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 3324.426865] SET = 0, FnV = 0<br /> [ 3324.429913] EA = 0, S1PTW = 0<br /> [ 3324.433047] Data abort info:<br /> [ 3324.435921] ISV = 0, ISS = 0x00000006<br /> [ 3324.439748] CM = 0, WnR = 0<br /> ....<br /> [ 3324.575915] Call trace:<br /> [ 3324.578353] cn10k_mdo_del_secy+0x24/0x180<br /> [ 3324.582440] macsec_common_dellink+0xec/0x120<br /> [ 3324.586788] macsec_notify+0x17c/0x1c0<br /> [ 3324.590529] raw_notifier_call_chain+0x50/0x70<br /> [ 3324.594965] call_netdevice_notifiers_info+0x34/0x7c<br /> [ 3324.599921] rollback_registered_many+0x354/0x5bc<br /> [ 3324.604616] unregister_netdevice_queue+0x88/0x10c<br /> [ 3324.609399] unregister_netdev+0x20/0x30<br /> [ 3324.613313] otx2_remove+0x8c/0x310<br /> [ 3324.616794] pci_device_shutdown+0x30/0x70<br /> [ 3324.620882] device_shutdown+0x11c/0x204<br /> <br /> [ 966.664930] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 966.673712] Mem abort info:<br /> [ 966.676497] ESR = 0x96000006<br /> [ 966.679543] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 966.684848] SET = 0, FnV = 0<br /> [ 966.687895] EA = 0, S1PTW = 0<br /> [ 966.691028] Data abort info:<br /> [ 966.693900] ISV = 0, ISS = 0x00000006<br /> [ 966.697729] CM = 0, WnR = 0<br /> [ 966.833467] Call trace:<br /> [ 966.835904] cn10k_mdo_stop+0x20/0xa0<br /> [ 966.839557] macsec_dev_stop+0xe8/0x11c<br /> [ 966.843384] __dev_close_many+0xbc/0x140<br /> [ 966.847298] dev_close_many+0x84/0x120<br /> [ 966.851039] rollback_registered_many+0x114/0x5bc<br /> [ 966.855735] unregister_netdevice_many.part.0+0x14/0xa0<br /> [ 966.860952] unregister_netdevice_many+0x18/0x24<br /> [ 966.865560] macsec_notify+0x1ac/0x1c0<br /> [ 966.869303] raw_notifier_call_chain+0x50/0x70<br /> [ 966.873738] call_netdevice_notifiers_info+0x34/0x7c<br /> [ 966.878694] rollback_registered_many+0x354/0x5bc<br /> [ 966.883390] unregister_netdevice_queue+0x88/0x10c<br /> [ 966.888173] unregister_netdev+0x20/0x30<br /> [ 966.892090] otx2_remove+0x8c/0x310<br /> [ 966.895571] pci_device_shutdown+0x30/0x70<br /> [ 966.899660] device_shutdown+0x11c/0x204<br /> [ 966.903574] __do_sys_reboot+0x208/0x290<br /> [ 966.907487] __arm64_sys_reboot+0x20/0x30<br /> [ 966.911489] el0_svc_handler+0x80/0x1c0<br /> [ 966.915316] el0_svc+0x8/0x180<br /> [ 966.918362] Code: f9400000 f9400a64 91220014 f94b3403 (f9400060)<br /> [ 966.924448] ---[ end trace 341778e799c3d8d7 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: base: Free devm resources when unregistering a device<br /> <br /> In the current code, devres_release_all() only gets called if the device<br /> has a bus and has been probed.<br /> <br /> This leads to issues when using bus-less or driver-less devices where<br /> the device might never get freed if a managed resource holds a reference<br /> to the device. This is happening in the DRM framework for example.<br /> <br /> We should thus call devres_release_all() in the device_del() function to<br /> make sure that the device-managed actions are properly executed when the<br /> device is unregistered, even if it has neither a bus nor a driver.<br /> <br /> This is effectively the same change than commit 2f8d16a996da ("devres:<br /> release resources on device_del()") that got reverted by commit<br /> a525a3ddeaca ("driver core: free devres in device_release") over<br /> memory leaks concerns.<br /> <br /> This patch effectively combines the two commits mentioned above to<br /> release the resources both on device_del() and device_release() and get<br /> the best of both worlds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix mid leak during reconnection after timeout threshold<br /> <br /> When the number of responses with status of STATUS_IO_TIMEOUT<br /> exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect<br /> the connection. But we do not return the mid, or the credits<br /> returned for the mid, or reduce the number of in-flight requests.<br /> <br /> This bug could result in the server-&gt;in_flight count to go bad,<br /> and also cause a leak in the mids.<br /> <br /> This change moves the check to a few lines below where the<br /> response is decrypted, even of the response is read from the<br /> transform header. This way, the code for returning the mids<br /> can be reused.<br /> <br /> Also, the cifs_reconnect was reconnecting just the transport<br /> connection before. In case of multi-channel, this may not be<br /> what we want to do after several timeouts. Changed that to<br /> reconnect the session and the tree too.<br /> <br /> Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name<br /> MAX_STATUS_IO_TIMEOUT.