Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix deadlock between bd_link_disk_holder and partition scan<br /> <br /> &amp;#39;open_mutex&amp;#39; of gendisk is used to protect open/close block devices. But<br /> in bd_link_disk_holder(), it is used to protect the creation of symlink<br /> between holding disk and slave bdev, which introduces some issues.<br /> <br /> When bd_link_disk_holder() is called, the driver is usually in the process<br /> of initialization/modification and may suspend submitting io. At this<br /> time, any io hold &amp;#39;open_mutex&amp;#39;, such as scanning partitions, can cause<br /> deadlocks. For example, in raid:<br /> <br /> T1 T2<br /> bdev_open_by_dev<br /> lock open_mutex [1]<br /> ...<br /> efi_partition<br /> ...<br /> md_submit_bio<br /> md_ioctl mddev_syspend<br /> -&gt; suspend all io<br /> md_add_new_disk<br /> bind_rdev_to_array<br /> bd_link_disk_holder<br /> try lock open_mutex [2]<br /> md_handle_request<br /> -&gt; wait mddev_resume<br /> <br /> T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume<br /> mddev, but T2 waits for open_mutex held by T1. Deadlock occurs.<br /> <br /> Fix it by introducing a local mutex &amp;#39;blk_holder_mutex&amp;#39; to replace<br /> &amp;#39;open_mutex&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix kmemleak of rdev-&gt;serial<br /> <br /> If kobject_add() is fail in bind_rdev_to_array(), &amp;#39;rdev-&gt;serial&amp;#39; will be<br /> alloc not be freed, and kmemleak occurs.<br /> <br /> unreferenced object 0xffff88815a350000 (size 49152):<br /> comm "mdadm", pid 789, jiffies 4294716910<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc f773277a):<br /> [] kmemleak_alloc+0x61/0xe0<br /> [] __kmalloc_large_node+0x15e/0x270<br /> [] __kmalloc_node.cold+0x11/0x7f<br /> [] kvmalloc_node+0x74/0x150<br /> [] rdev_init_serial+0x67/0x170<br /> [] mddev_create_serial_pool+0x62/0x220<br /> [] bind_rdev_to_array+0x2af/0x630<br /> [] md_add_new_disk+0x400/0x9f0<br /> [] md_ioctl+0x15bf/0x1c10<br /> [] blkdev_ioctl+0x191/0x3f0<br /> [] vfs_ioctl+0x22/0x60<br /> [] __x64_sys_ioctl+0xba/0xe0<br /> [] do_syscall_64+0x71/0x150<br /> [] entry_SYSCALL_64_after_hwframe+0x6c/0x74

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()<br /> <br /> After unregistering the CPU idle device, the memory associated with<br /> it is not freed, leading to a memory leak:<br /> <br /> unreferenced object 0xffff896282f6c000 (size 1024):<br /> comm "swapper/0", pid 1, jiffies 4294893170<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 8836a742):<br /> [] kmalloc_trace+0x29d/0x340<br /> [] acpi_processor_power_init+0xf3/0x1c0<br /> [] __acpi_processor_start+0xd3/0xf0<br /> [] acpi_processor_start+0x2c/0x50<br /> [] really_probe+0xe2/0x480<br /> [] __driver_probe_device+0x78/0x160<br /> [] driver_probe_device+0x1f/0x90<br /> [] __driver_attach+0xce/0x1c0<br /> [] bus_for_each_dev+0x70/0xc0<br /> [] bus_add_driver+0x112/0x210<br /> [] driver_register+0x55/0x100<br /> [] acpi_processor_driver_init+0x3b/0xc0<br /> [] do_one_initcall+0x41/0x300<br /> [] kernel_init_freeable+0x320/0x470<br /> [] kernel_init+0x16/0x1b0<br /> [] ret_from_fork+0x2d/0x50<br /> <br /> Fix this by freeing the CPU idle device after unregistering it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()<br /> <br /> Apply the same fix than ones found in :<br /> <br /> 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")<br /> 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")<br /> <br /> We have to save skb-&gt;network_header in a temporary variable<br /> in order to be able to recompute the network_header pointer<br /> after a pskb_inet_may_pull() call.<br /> <br /> pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.<br /> <br /> syzbot reported:<br /> BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]<br /> BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409<br /> __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]<br /> INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]<br /> IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]<br /> ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409<br /> __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389<br /> ipgre_rcv net/ipv4/ip_gre.c:411 [inline]<br /> gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447<br /> gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163<br /> ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254<br /> dst_input include/net/dst.h:461 [inline]<br /> ip_rcv_finish net/ipv4/ip_input.c:449 [inline]<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569<br /> __netif_receive_skb_one_core net/core/dev.c:5534 [inline]<br /> __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648<br /> netif_receive_skb_internal net/core/dev.c:5734 [inline]<br /> netif_receive_skb+0x58/0x660 net/core/dev.c:5793<br /> tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556<br /> tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055<br /> call_write_iter include/linux/fs.h:2087 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xb6b/0x1520 fs/read_write.c:590<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was created at:<br /> __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590<br /> alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133<br /> alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204<br /> skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909<br /> tun_build_skb drivers/net/tun.c:1686 [inline]<br /> tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826<br /> tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055<br /> call_write_iter include/linux/fs.h:2087 [inline]<br /> new_sync_write fs/read_write.c:497 [inline]<br /> vfs_write+0xb6b/0x1520 fs/read_write.c:590<br /> ksys_write+0x20f/0x4c0 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __x64_sys_write+0x93/0xd0 fs/read_write.c:652<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stackmap overflow check on 32-bit arches<br /> <br /> The stackmap code relies on roundup_pow_of_two() to compute the number<br /> of hash buckets, and contains an overflow check by checking if the<br /> resulting value is 0. However, on 32-bit arches, the roundup code itself<br /> can overflow by doing a 32-bit left-shift of an unsigned long value,<br /> which is undefined behaviour, so it is not guaranteed to truncate<br /> neatly. This was triggered by syzbot on the DEVMAP_HASH type, which<br /> contains the same check, copied from the hashtab code.<br /> <br /> The commit in the fixes tag actually attempted to fix this, but the fix<br /> did not account for the UB, so the fix only works on CPUs where an<br /> overflow does result in a neat truncation to zero, which is not<br /> guaranteed. Checking the value before rounding does not have this<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix hashtab overflow check on 32-bit arches<br /> <br /> The hashtab code relies on roundup_pow_of_two() to compute the number of<br /> hash buckets, and contains an overflow check by checking if the<br /> resulting value is 0. However, on 32-bit arches, the roundup code itself<br /> can overflow by doing a 32-bit left-shift of an unsigned long value,<br /> which is undefined behaviour, so it is not guaranteed to truncate<br /> neatly. This was triggered by syzbot on the DEVMAP_HASH type, which<br /> contains the same check, copied from the hashtab code. So apply the same<br /> fix to hashtab, by moving the overflow check to before the roundup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix DEVMAP_HASH overflow check on 32-bit arches<br /> <br /> The devmap code allocates a number hash buckets equal to the next power<br /> of two of the max_entries value provided when creating the map. When<br /> rounding up to the next power of two, the 32-bit variable storing the<br /> number of buckets can overflow, and the code checks for overflow by<br /> checking if the truncated 32-bit value is equal to 0. However, on 32-bit<br /> arches the rounding up itself can overflow mid-way through, because it<br /> ends up doing a left-shift of 32 bits on an unsigned long value. If the<br /> size of an unsigned long is four bytes, this is undefined behaviour, so<br /> there is no guarantee that we&amp;#39;ll end up with a nice and tidy 0-value at<br /> the end.<br /> <br /> Syzbot managed to turn this into a crash on arm32 by creating a<br /> DEVMAP_HASH with max_entries &gt; 0x80000000 and then trying to update it.<br /> Fix this by moving the overflow check to before the rounding up<br /> operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: Fix possible buffer overflow<br /> <br /> struct hci_dev_info has a fixed size name[8] field so in the event that<br /> hdev-&gt;name is bigger than that strcpy would attempt to write past its<br /> size, so this fixes this problem by switching to use strscpy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Don&amp;#39;t issue ATS Invalidation request when device is disconnected<br /> <br /> For those endpoint devices connect to system via hotplug capable ports,<br /> users could request a hot reset to the device by flapping device&amp;#39;s link<br /> through setting the slot&amp;#39;s link control register, as pciehp_ist() DLLSC<br /> interrupt sequence response, pciehp will unload the device driver and<br /> then power it off. thus cause an IOMMU device-TLB invalidation (Intel<br /> VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence<br /> target device to be sent and deadly loop to retry that request after ITE<br /> fault triggered in interrupt context.<br /> <br /> That would cause following continuous hard lockup warning and system hang<br /> <br /> [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down<br /> [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present<br /> [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144<br /> [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S<br /> OE kernel version xxxx<br /> [ 4223.822623] Hardware name: vendorname xxxx 666-106,<br /> BIOS 01.01.02.03.01 05/15/2023<br /> [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490<br /> [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b<br /> 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 f6 c6 1<br /> 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39<br /> [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093<br /> [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005<br /> [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340<br /> [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000<br /> [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200<br /> [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004<br /> [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000)<br /> knlGS:0000000000000000<br /> [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0<br /> [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 4223.822628] PKRU: 55555554<br /> [ 4223.822628] Call Trace:<br /> [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0<br /> [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250<br /> [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50<br /> [ 4223.822629] intel_iommu_release_device+0x1f/0x30<br /> [ 4223.822629] iommu_release_device+0x33/0x60<br /> [ 4223.822629] iommu_bus_notifier+0x7f/0x90<br /> [ 4223.822630] blocking_notifier_call_chain+0x60/0x90<br /> [ 4223.822630] device_del+0x2e5/0x420<br /> [ 4223.822630] pci_remove_bus_device+0x70/0x110<br /> [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130<br /> [ 4223.822631] pciehp_disable_slot+0x6b/0x100<br /> [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320<br /> [ 4223.822631] pciehp_ist+0x176/0x180<br /> [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110<br /> [ 4223.822632] irq_thread_fn+0x19/0x50<br /> [ 4223.822632] irq_thread+0x104/0x190<br /> [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90<br /> [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0<br /> [ 4223.822633] kthread+0x114/0x130<br /> [ 4223.822633] ? __kthread_cancel_work+0x40/0x40<br /> [ 4223.822633] ret_from_fork+0x1f/0x30<br /> [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP<br /> [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S<br /> OE kernel version xxxx<br /> [ 4223.822634] Hardware name: vendorname xxxx 666-106,<br /> BIOS 01.01.02.03.01 05/15/2023<br /> [ 4223.822634] Call Trace:<br /> [ 4223.822634] <br /> [ 4223.822635] dump_stack+0x6d/0x88<br /> [ 4223.822635] panic+0x101/0x2d0<br /> [ 4223.822635] ? ret_from_fork+0x11/0x30<br /> [ 4223.822635] nmi_panic.cold.14+0xc/0xc<br /> [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81<br /> [ 4223.822636] __perf_event_overflow+0x4f/0xf0<br /> [ 4223.822636] handle_pmi_common<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces<br /> <br /> wilc_netdev_cleanup currently triggers a KASAN warning, which can be<br /> observed on interface registration error path, or simply by<br /> removing the module/unbinding device from driver:<br /> <br /> echo spi0.1 &gt; /sys/bus/spi/drivers/wilc1000_spi/unbind<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc<br /> Read of size 4 at addr c54d1ce8 by task sh/86<br /> <br /> CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117<br /> Hardware name: Atmel SAMA5<br /> unwind_backtrace from show_stack+0x18/0x1c<br /> show_stack from dump_stack_lvl+0x34/0x58<br /> dump_stack_lvl from print_report+0x154/0x500<br /> print_report from kasan_report+0xac/0xd8<br /> kasan_report from wilc_netdev_cleanup+0x508/0x5cc<br /> wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec<br /> wilc_bus_remove from spi_remove+0x8c/0xac<br /> spi_remove from device_release_driver_internal+0x434/0x5f8<br /> device_release_driver_internal from unbind_store+0xbc/0x108<br /> unbind_store from kernfs_fop_write_iter+0x398/0x584<br /> kernfs_fop_write_iter from vfs_write+0x728/0xf88<br /> vfs_write from ksys_write+0x110/0x1e4<br /> ksys_write from ret_fast_syscall+0x0/0x1c<br /> <br /> [...]<br /> <br /> Allocated by task 1:<br /> kasan_save_track+0x30/0x5c<br /> __kasan_kmalloc+0x8c/0x94<br /> __kmalloc_node+0x1cc/0x3e4<br /> kvmalloc_node+0x48/0x180<br /> alloc_netdev_mqs+0x68/0x11dc<br /> alloc_etherdev_mqs+0x28/0x34<br /> wilc_netdev_ifc_init+0x34/0x8ec<br /> wilc_cfg80211_init+0x690/0x910<br /> wilc_bus_probe+0xe0/0x4a0<br /> spi_probe+0x158/0x1b0<br /> really_probe+0x270/0xdf4<br /> __driver_probe_device+0x1dc/0x580<br /> driver_probe_device+0x60/0x140<br /> __driver_attach+0x228/0x5d4<br /> bus_for_each_dev+0x13c/0x1a8<br /> bus_add_driver+0x2a0/0x608<br /> driver_register+0x24c/0x578<br /> do_one_initcall+0x180/0x310<br /> kernel_init_freeable+0x424/0x484<br /> kernel_init+0x20/0x148<br /> ret_from_fork+0x14/0x28<br /> <br /> Freed by task 86:<br /> kasan_save_track+0x30/0x5c<br /> kasan_save_free_info+0x38/0x58<br /> __kasan_slab_free+0xe4/0x140<br /> kfree+0xb0/0x238<br /> device_release+0xc0/0x2a8<br /> kobject_put+0x1d4/0x46c<br /> netdev_run_todo+0x8fc/0x11d0<br /> wilc_netdev_cleanup+0x1e4/0x5cc<br /> wilc_bus_remove+0xc8/0xec<br /> spi_remove+0x8c/0xac<br /> device_release_driver_internal+0x434/0x5f8<br /> unbind_store+0xbc/0x108<br /> kernfs_fop_write_iter+0x398/0x584<br /> vfs_write+0x728/0xf88<br /> ksys_write+0x110/0x1e4<br /> ret_fast_syscall+0x0/0x1c<br /> [...]<br /> <br /> David Mosberger-Tan initial investigation [1] showed that this<br /> use-after-free is due to netdevice unregistration during vif list<br /> traversal. When unregistering a net device, since the needs_free_netdev has<br /> been set to true during registration, the netdevice object is also freed,<br /> and as a consequence, the corresponding vif object too, since it is<br /> attached to it as private netdevice data. The next occurrence of the loop<br /> then tries to access freed vif pointer to the list to move forward in the<br /> list.<br /> <br /> Fix this use-after-free thanks to two mechanisms:<br /> - navigate in the list with list_for_each_entry_safe, which allows to<br /> safely modify the list as we go through each element. For each element,<br /> remove it from the list with list_del_rcu<br /> - make sure to wait for RCU grace period end after each vif removal to make<br /> sure it is safe to free the corresponding vif too (through<br /> unregister_netdev)<br /> <br /> Since we are in a RCU "modifier" path (not a "reader" path), and because<br /> such path is expected not to be concurrent to any other modifier (we are<br /> using the vif_mutex lock), we do not need to use RCU list API, that&amp;#39;s why<br /> we can benefit from list_for_each_entry_safe.<br /> <br /> [1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete<br /> <br /> The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data<br /> structures have been fully initialised by the time it runs. However, because of<br /> the order in which things are initialised, this is not guaranteed to be the<br /> case, because the device is exposed to the USB subsystem before the ath9k driver<br /> initialisation is completed.<br /> <br /> We already committed a partial fix for this in commit:<br /> 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")<br /> <br /> However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event<br /> tasklet, pairing it with an "initialisation complete" bit in the TX struct. It<br /> seems syzbot managed to trigger the race for one of the other commands as well,<br /> so let&amp;#39;s just move the existing synchronisation bit to cover the whole<br /> tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside<br /> ath9k_tx_init()).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts<br /> <br /> This patch is against CVE-2023-6270. The description of cve is:<br /> <br /> A flaw was found in the ATA over Ethernet (AoE) driver in the Linux<br /> kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on<br /> `struct net_device`, and a use-after-free can be triggered by racing<br /> between the free on the struct and the access through the `skbtxq`<br /> global queue. This could lead to a denial of service condition or<br /> potential code execution.<br /> <br /> In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial<br /> code is finished. But the net_device ifp will still be used in<br /> later tx()-&gt;dev_queue_xmit() in kthread. Which means that the<br /> dev_put(ifp) should NOT be called in the success path of skb<br /> initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into<br /> use-after-free because the net_device is freed.<br /> <br /> This patch removed the dev_put(ifp) in the success path in<br /> aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().