Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-core: fix dev_pm_qos memleak<br /> <br /> Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to<br /> avoid following kmemleak:-<br /> <br /> blktests (master) # kmemleak-clear; ./check nvme/044;<br /> blktests (master) # kmemleak-scan ; kmemleak-show<br /> nvme/044 (Test bi-directional authentication) [passed]<br /> runtime 2.111s ... 2.124s<br /> unreferenced object 0xffff888110c46240 (size 96):<br /> comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s)<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:<br /> [] kmalloc_trace+0x25/0x90<br /> [] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100<br /> [] nvme_init_ctrl+0x38e/0x410 [nvme_core]<br /> [] 0xffffffffc05e88b3<br /> [] 0xffffffffc05744cb<br /> [] vfs_write+0xc5/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix skb_copy_ubufs() vs BIG TCP<br /> <br /> David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy<br /> using hugepages, and skb length bigger than ~68 KB.<br /> <br /> skb_copy_ubufs() assumed it could copy all payload using up to<br /> MAX_SKB_FRAGS order-0 pages.<br /> <br /> This assumption broke when BIG TCP was able to put up to 512 KB per skb.<br /> <br /> We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45<br /> and limit gso_max_size to 180000.<br /> <br /> A solution is to use higher order pages if needed.<br /> <br /> v2: add missing __GFP_COMP, or we leak memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed<br /> <br /> Registering a kprobe on __rcu_irq_enter_check_tick() can cause kernel<br /> stack overflow as shown below. This issue can be reproduced by enabling<br /> CONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=",<br /> and then giving the following commands at the shell prompt:<br /> <br /> # cd /sys/kernel/tracing/<br /> # echo &amp;#39;p:mp1 __rcu_irq_enter_check_tick&amp;#39; &gt;&gt; kprobe_events<br /> # echo 1 &gt; events/kprobes/enable<br /> <br /> This commit therefore adds __rcu_irq_enter_check_tick() to the kprobes<br /> blacklist using NOKPROBE_SYMBOL().<br /> <br /> Insufficient stack space to handle exception!<br /> ESR: 0x00000000f2000004 -- BRK (AArch64)<br /> FAR: 0x0000ffffccf3e510<br /> Task stack: [0xffff80000ad30000..0xffff80000ad38000]<br /> IRQ stack: [0xffff800008050000..0xffff800008058000]<br /> Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310]<br /> CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __rcu_irq_enter_check_tick+0x0/0x1b8<br /> lr : ct_nmi_enter+0x11c/0x138<br /> sp : ffff80000ad30080<br /> x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000<br /> x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148<br /> x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c<br /> x14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809<br /> x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000<br /> x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001<br /> x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4<br /> x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000<br /> Kernel panic - not syncing: kernel stack overflow<br /> CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0xf8/0x108<br /> show_stack+0x20/0x30<br /> dump_stack_lvl+0x68/0x84<br /> dump_stack+0x1c/0x38<br /> panic+0x214/0x404<br /> add_taint+0x0/0xf8<br /> panic_bad_stack+0x144/0x160<br /> handle_bad_stack+0x38/0x58<br /> __bad_stack+0x78/0x7c<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> [...]<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> arm64_enter_el1_dbg.isra.0+0x14/0x20<br /> el1_dbg+0x2c/0x90<br /> el1h_64_sync_handler+0xcc/0xe8<br /> el1h_64_sync+0x64/0x68<br /> __rcu_irq_enter_check_tick+0x0/0x1b8<br /> el1_interrupt+0x28/0x60<br /> el1h_64_irq_handler+0x18/0x28<br /> el1h_64_irq+0x64/0x68<br /> __ftrace_set_clr_event_nolock+0x98/0x198<br /> __ftrace_set_clr_event+0x58/0x80<br /> system_enable_write+0x144/0x178<br /> vfs_write+0x174/0x738<br /> ksys_write+0xd0/0x188<br /> __arm64_sys_write+0x4c/0x60<br /> invoke_syscall+0x64/0x180<br /> el0_svc_common.constprop.0+0x84/0x160<br /> do_el0_svc+0x48/0xe8<br /> el0_svc+0x34/0xd0<br /> el0t_64_sync_handler+0xb8/0xc0<br /> el0t_64_sync+0x190/0x194<br /> SMP: stopping secondary CPUs<br /> Kernel Offset: 0x28da86000000 from 0xffff800008000000<br /> PHYS_OFFSET: 0xfffff76600000000<br /> CPU features: 0x00000,01a00100,0000421b<br /> Memory Limit: none

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/perf: hisi: Don&amp;#39;t migrate perf to the CPU going to teardown<br /> <br /> The driver needs to migrate the perf context if the current using CPU going<br /> to teardown. By the time calling the cpuhp::teardown() callback the<br /> cpu_online_mask() hasn&amp;#39;t updated yet and still includes the CPU going to<br /> teardown. In current driver&amp;#39;s implementation we may migrate the context<br /> to the teardown CPU and leads to the below calltrace:<br /> <br /> ...<br /> [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008<br /> [ 368.113699][ T932] Call trace:<br /> [ 368.116834][ T932] __switch_to+0x7c/0xbc<br /> [ 368.120924][ T932] __schedule+0x338/0x6f0<br /> [ 368.125098][ T932] schedule+0x50/0xe0<br /> [ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24<br /> [ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc<br /> [ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30<br /> [ 368.144573][ T932] mutex_lock+0x50/0x60<br /> [ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0<br /> [ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]<br /> [ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650<br /> [ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190<br /> [ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0<br /> [ 368.175099][ T932] kthread+0x108/0x13c<br /> [ 368.179012][ T932] ret_from_fork+0x10/0x18<br /> ...<br /> <br /> Use function cpumask_any_but() to find one correct active cpu to fixes<br /> this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Don&amp;#39;t tx before switchdev is fully configured<br /> <br /> There is possibility that ice_eswitch_port_start_xmit might be<br /> called while some resources are still not allocated which might<br /> cause NULL pointer dereference. Fix this by checking if switchdev<br /> configuration was finished.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: bcm-qspi: return error if neither hif_mspi nor mspi is available<br /> <br /> If neither a "hif_mspi" nor "mspi" resource is present, the driver will<br /> just early exit in probe but still return success. Apart from not doing<br /> anything meaningful, this would then also lead to a null pointer access<br /> on removal, as platform_get_drvdata() would return NULL, which it would<br /> then try to dereference when trying to unregister the spi master.<br /> <br /> Fix this by unconditionally calling devm_ioremap_resource(), as it can<br /> handle a NULL res and will then return a viable ERR_PTR() if we get one.<br /> <br /> The "return 0;" was previously a "goto qspi_resource_err;" where then<br /> ret was returned, but since ret was still initialized to 0 at this place<br /> this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix<br /> use-after-free on unbind"). The issue was not introduced by this commit,<br /> only made more obvious.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt: avoid overflow in bnxt_get_nvram_directory()<br /> <br /> The value of an arithmetic expression is subject<br /> of possible overflow due to a failure to cast operands to a larger data<br /> type before performing arithmetic. Used macro for multiplication instead<br /> operator for avoiding overflow.<br /> <br /> Found by Security Code and Linux Verification<br /> Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}<br /> <br /> If the filename casefolding fails, we&amp;#39;ll be leaking memory from the<br /> fscrypt_name struct, namely from the &amp;#39;crypto_buf.name&amp;#39; member.<br /> <br /> Make sure we free it in the error path on both ext4_fname_setup_filename()<br /> and ext4_fname_prepare_lookup() functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix out-of-bounds when setting channels on remove<br /> <br /> If we set channels greater during iavf_remove(), and waiting reset done<br /> would be timeout, then returned with error but changed num_active_queues<br /> directly, that will lead to OOB like the following logs. Because the<br /> num_active_queues is greater than tx/rx_rings[] allocated actually.<br /> <br /> Reproducer:<br /> <br /> [root@host ~]# cat repro.sh<br /> #!/bin/bash<br /> <br /> pf_dbsf="0000:41:00.0"<br /> vf0_dbsf="0000:41:02.0"<br /> g_pids=()<br /> <br /> function do_set_numvf()<br /> {<br /> echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> }<br /> <br /> function do_set_channel()<br /> {<br /> local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)<br /> [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }<br /> ifconfig $nic 192.168.18.5 netmask 255.255.255.0<br /> ifconfig $nic up<br /> ethtool -L $nic combined 1<br /> ethtool -L $nic combined 4<br /> sleep $((RANDOM%3))<br /> }<br /> <br /> function on_exit()<br /> {<br /> local pid<br /> for pid in "${g_pids[@]}"; do<br /> kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null<br /> done<br /> g_pids=()<br /> }<br /> <br /> trap "on_exit; exit" EXIT<br /> <br /> while :; do do_set_numvf ; done &amp;<br /> g_pids+=($!)<br /> while :; do do_set_channel ; done &amp;<br /> g_pids+=($!)<br /> <br /> wait<br /> <br /> Result:<br /> <br /> [ 3506.152887] iavf 0000:41:02.0: Removing device<br /> [ 3510.400799] ==================================================================<br /> [ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536<br /> [ 3510.400823]<br /> [ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1<br /> [ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021<br /> [ 3510.400835] Call Trace:<br /> [ 3510.400851] dump_stack+0x71/0xab<br /> [ 3510.400860] print_address_description+0x6b/0x290<br /> [ 3510.400865] ? iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400868] kasan_report+0x14a/0x2b0<br /> [ 3510.400873] iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400880] iavf_remove+0x2b6/0xc70 [iavf]<br /> [ 3510.400884] ? iavf_free_all_rx_resources+0x160/0x160 [iavf]<br /> [ 3510.400891] ? wait_woken+0x1d0/0x1d0<br /> [ 3510.400895] ? notifier_call_chain+0xc1/0x130<br /> [ 3510.400903] pci_device_remove+0xa8/0x1f0<br /> [ 3510.400910] device_release_driver_internal+0x1c6/0x460<br /> [ 3510.400916] pci_stop_bus_device+0x101/0x150<br /> [ 3510.400919] pci_stop_and_remove_bus_device+0xe/0x20<br /> [ 3510.400924] pci_iov_remove_virtfn+0x187/0x420<br /> [ 3510.400927] ? pci_iov_add_virtfn+0xe10/0xe10<br /> [ 3510.400929] ? pci_get_subsys+0x90/0x90<br /> [ 3510.400932] sriov_disable+0xed/0x3e0<br /> [ 3510.400936] ? bus_find_device+0x12d/0x1a0<br /> [ 3510.400953] i40e_free_vfs+0x754/0x1210 [i40e]<br /> [ 3510.400966] ? i40e_reset_all_vfs+0x880/0x880 [i40e]<br /> [ 3510.400968] ? pci_get_device+0x7c/0x90<br /> [ 3510.400970] ? pci_get_subsys+0x90/0x90<br /> [ 3510.400982] ? pci_vfs_assigned.part.7+0x144/0x210<br /> [ 3510.400987] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 3510.400996] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]<br /> [ 3510.401001] sriov_numvfs_store+0x214/0x290<br /> [ 3510.401005] ? sriov_totalvfs_show+0x30/0x30<br /> [ 3510.401007] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 3510.401011] ? __check_object_size+0x15a/0x350<br /> [ 3510.401018] kernfs_fop_write+0x280/0x3f0<br /> [ 3510.401022] vfs_write+0x145/0x440<br /> [ 3510.401025] ksys_write+0xab/0x160<br /> [ 3510.401028] ? __ia32_sys_read+0xb0/0xb0<br /> [ 3510.401031] ? fput_many+0x1a/0x120<br /> [ 3510.401032] ? filp_close+0xf0/0x130<br /> [ 3510.401038] do_syscall_64+0xa0/0x370<br /> [ 3510.401041] ? page_fault+0x8/0x30<br /> [ 3510.401043] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> [ 3510.401073] RIP: 0033:0x7f3a9bb842c0<br /> [ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 3d <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, cpumap: Handle skb as well when clean up ptr_ring<br /> <br /> The following warning was reported when running xdp_redirect_cpu with<br /> both skb-mode and stress-mode enabled:<br /> <br /> ------------[ cut here ]------------<br /> Incorrect XDP memory type (-2128176192) usage<br /> WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405<br /> Modules linked in:<br /> CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: events __cpu_map_entry_free<br /> RIP: 0010:__xdp_return+0x1e4/0x4a0<br /> ......<br /> Call Trace:<br /> <br /> ? show_regs+0x65/0x70<br /> ? __warn+0xa5/0x240<br /> ? __xdp_return+0x1e4/0x4a0<br /> ......<br /> xdp_return_frame+0x4d/0x150<br /> __cpu_map_entry_free+0xf9/0x230<br /> process_one_work+0x6b0/0xb80<br /> worker_thread+0x96/0x720<br /> kthread+0x1a5/0x1f0<br /> ret_from_fork+0x3a/0x70<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The reason for the warning is twofold. One is due to the kthread<br /> cpu_map_kthread_run() is stopped prematurely. Another one is<br /> __cpu_map_ring_cleanup() doesn&amp;#39;t handle skb mode and treats skbs in<br /> ptr_ring as XDP frames.<br /> <br /> Prematurely-stopped kthread will be fixed by the preceding patch and<br /> ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But<br /> as the comments in __cpu_map_ring_cleanup() said, handling and freeing<br /> skbs in ptr_ring as well to "catch any broken behaviour gracefully".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Don&amp;#39;t dereference ACPI root object handle<br /> <br /> Since the commit referenced in the Fixes: tag below the VMBus client driver<br /> is walking the ACPI namespace up from the VMBus ACPI device to the ACPI<br /> namespace root object trying to find Hyper-V MMIO ranges.<br /> <br /> However, if it is not able to find them it ends trying to walk resources of<br /> the ACPI namespace root object itself.<br /> This object has all-ones handle, which causes a NULL pointer dereference<br /> in the ACPI code (from dereferencing this pointer with an offset).<br /> <br /> This in turn causes an oops on boot with VMBus host implementations that do<br /> not provide Hyper-V MMIO ranges in their VMBus ACPI device or its<br /> ancestors.<br /> The QEMU VMBus implementation is an example of such implementation.<br /> <br /> I guess providing these ranges is optional, since all tested Windows<br /> versions seem to be able to use VMBus devices without them.<br /> <br /> Fix this by explicitly terminating the lookup at the ACPI namespace root<br /> object.<br /> <br /> Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interface<br /> by default - they only do so if the KVM PV interface is missing or<br /> disabled.<br /> <br /> Example stack trace of such oops:<br /> [ 3.710827] ? __die+0x1f/0x60<br /> [ 3.715030] ? page_fault_oops+0x159/0x460<br /> [ 3.716008] ? exc_page_fault+0x73/0x170<br /> [ 3.716959] ? asm_exc_page_fault+0x22/0x30<br /> [ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0<br /> [ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0<br /> [ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0<br /> [ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200<br /> [ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0<br /> [ 3.723559] ? down_timeout+0x3a/0x60<br /> [ 3.724455] ? acpi_ns_get_node+0x3a/0x60<br /> [ 3.725412] acpi_ns_get_node+0x3a/0x60<br /> [ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0<br /> [ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0<br /> [ 3.728400] acpi_rs_get_method_data+0x2b/0x70<br /> [ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]<br /> [ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]<br /> [ 3.732411] acpi_walk_resources+0x78/0xd0<br /> [ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]<br /> [ 3.734802] platform_probe+0x3d/0x90<br /> [ 3.735684] really_probe+0x19b/0x400<br /> [ 3.736570] ? __device_attach_driver+0x100/0x100<br /> [ 3.737697] __driver_probe_device+0x78/0x160<br /> [ 3.738746] driver_probe_device+0x1f/0x90<br /> [ 3.739743] __driver_attach+0xc2/0x1b0<br /> [ 3.740671] bus_for_each_dev+0x70/0xc0<br /> [ 3.741601] bus_add_driver+0x10e/0x210<br /> [ 3.742527] driver_register+0x55/0xf0<br /> [ 3.744412] ? 0xffffffffc039a000<br /> [ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer<br /> <br /> smatch error:<br /> sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:<br /> we previously assumed &amp;#39;rac97&amp;#39; could be null (see line 2072)<br /> <br /> remove redundant assignment, return error if rac97 is NULL.