Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sun8i-ce - Fix use after free in unprepare<br /> <br /> sun8i_ce_cipher_unprepare should be called before<br /> crypto_finalize_skcipher_request, because client callbacks may<br /> immediately free memory, that isn&amp;#39;t needed anymore. But it will be<br /> used by unprepare after free. Before removing prepare/unprepare<br /> callbacks it was handled by crypto engine in crypto_finalize_request.<br /> <br /> Usually that results in a pointer dereference problem during a in<br /> crypto selftest.<br /> Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000030<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000004716d000<br /> [0000000000000030] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> <br /> This problem is detected by KASAN as well.<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce]<br /> Read of size 8 at addr ffff00000dcdc040 by task 1c15000.crypto-/373<br /> <br /> Hardware name: Pine64 PinePhone (1.2) (DT)<br /> Call trace:<br /> dump_backtrace+0x9c/0x128<br /> show_stack+0x20/0x38<br /> dump_stack_lvl+0x48/0x60<br /> print_report+0xf8/0x5d8<br /> kasan_report+0x90/0xd0<br /> __asan_load8+0x9c/0xc0<br /> sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce]<br /> crypto_pump_work+0x354/0x620 [crypto_engine]<br /> kthread_worker_fn+0x244/0x498<br /> kthread+0x168/0x178<br /> ret_from_fork+0x10/0x20<br /> <br /> Allocated by task 379:<br /> kasan_save_stack+0x3c/0x68<br /> kasan_set_track+0x2c/0x40<br /> kasan_save_alloc_info+0x24/0x38<br /> __kasan_kmalloc+0xd4/0xd8<br /> __kmalloc+0x74/0x1d0<br /> alg_test_skcipher+0x90/0x1f0<br /> alg_test+0x24c/0x830<br /> cryptomgr_test+0x38/0x60<br /> kthread+0x168/0x178<br /> ret_from_fork+0x10/0x20<br /> <br /> Freed by task 379:<br /> kasan_save_stack+0x3c/0x68<br /> kasan_set_track+0x2c/0x40<br /> kasan_save_free_info+0x38/0x60<br /> __kasan_slab_free+0x100/0x170<br /> slab_free_freelist_hook+0xd4/0x1e8<br /> __kmem_cache_free+0x15c/0x290<br /> kfree+0x74/0x100<br /> kfree_sensitive+0x80/0xb0<br /> alg_test_skcipher+0x12c/0x1f0<br /> alg_test+0x24c/0x830<br /> cryptomgr_test+0x38/0x60<br /> kthread+0x168/0x178<br /> ret_from_fork+0x10/0x20<br /> <br /> The buggy address belongs to the object at ffff00000dcdc000<br /> which belongs to the cache kmalloc-256 of size 256<br /> The buggy address is located 64 bytes inside of<br /> freed 256-byte region [ffff00000dcdc000, ffff00000dcdc100)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nouveau: lock the client object tree.<br /> <br /> It appears the client object tree has no locking unless I&amp;#39;ve missed<br /> something else. Fix races around adding/removing client objects,<br /> mostly vram bar mappings.<br /> <br /> 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI<br /> [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27<br /> [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021<br /> [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]<br /> [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe<br /> [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206<br /> [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58<br /> [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400<br /> [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000<br /> [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0<br /> [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007<br /> [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000<br /> [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0<br /> [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 4562.099544] Call Trace:<br /> [ 4562.099555] <br /> [ 4562.099573] ? die_addr+0x36/0x90<br /> [ 4562.099583] ? exc_general_protection+0x246/0x4a0<br /> [ 4562.099593] ? asm_exc_general_protection+0x26/0x30<br /> [ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau]<br /> [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau]<br /> [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau]<br /> [ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]<br /> [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0<br /> [ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]<br /> [ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270<br /> [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau]<br /> [ 4562.100356] __do_fault+0x32/0x150<br /> [ 4562.100362] do_fault+0x7c/0x560<br /> [ 4562.100369] __handle_mm_fault+0x800/0xc10<br /> [ 4562.100382] handle_mm_fault+0x17c/0x3e0<br /> [ 4562.100388] do_user_addr_fault+0x208/0x860<br /> [ 4562.100395] exc_page_fault+0x7f/0x200<br /> [ 4562.100402] asm_exc_page_fault+0x26/0x30<br /> [ 4562.100412] RIP: 0033:0x9b9870<br /> [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7<br /> [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246<br /> [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000<br /> [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066<br /> [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000<br /> [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff<br /> [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000<br /> [ 4562.100446] <br /> [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> leds: trigger: netdev: Fix kernel panic on interface rename trig notify<br /> <br /> Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link<br /> speed mode") in the various changes, reworked the way to set the LINKUP<br /> mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck<br /> NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function.<br /> <br /> This changed the logic where, in the previous implementation the dev<br /> from the trigger event was used to check if the carrier was ok, but in<br /> the new implementation with the generic function, the dev in<br /> trigger_data is used instead.<br /> <br /> This is problematic and cause a possible kernel panic due to the fact<br /> that the dev in the trigger_data still reference the old one as the<br /> new one (passed from the trigger event) still has to be hold and saved<br /> in the trigger_data struct (done in the NETDEV_REGISTER case).<br /> <br /> On calling of get_device_state(), an invalid net_dev is used and this<br /> cause a kernel panic.<br /> <br /> To handle this correctly, move the call to get_device_state() after the<br /> new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER<br /> case) and correctly parse the new dev.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: Fix a memory leak in nf_tables_updchain<br /> <br /> If nft_netdev_register_hooks() fails, the memory associated with<br /> nft_stats is not freed, causing a memory leak.<br /> <br /> This patch fixes it by moving nft_stats_alloc() down after<br /> nft_netdev_register_hooks() succeeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio: packed: fix unmap leak for indirect desc table<br /> <br /> When use_dma_api and premapped are true, then the do_unmap is false.<br /> <br /> Because the do_unmap is false, vring_unmap_extra_packed is not called by<br /> detach_buf_packed.<br /> <br /> if (unlikely(vq-&gt;do_unmap)) {<br /> curr = id;<br /> for (i = 0; i num; i++) {<br /> vring_unmap_extra_packed(vq,<br /> &amp;vq-&gt;packed.desc_extra[curr]);<br /> curr = vq-&gt;packed.desc_extra[curr].next;<br /> }<br /> }<br /> <br /> So the indirect desc table is not unmapped. This causes the unmap leak.<br /> <br /> So here, we check vq-&gt;use_dma_api instead. Synchronously, dma info is<br /> updated based on use_dma_api judgment<br /> <br /> This bug does not occur, because no driver use the premapped with<br /> indirect.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen/evtchn: avoid WARN() when unbinding an event channel<br /> <br /> When unbinding a user event channel, the related handler might be<br /> called a last time in case the kernel was built with<br /> CONFIG_DEBUG_SHIRQ. This might cause a WARN() in the handler.<br /> <br /> Avoid that by adding an "unbinding" flag to struct user_event which<br /> will short circuit the handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path<br /> <br /> If devm_krealloc() fails, then &amp;#39;efuse&amp;#39; is leaking.<br /> So free it to avoid a leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: relax WARN_ON in ovl_verify_area()<br /> <br /> syzbot hit an assertion in copy up data loop which looks like it is<br /> the result of a lower file whose size is being changed underneath<br /> overlayfs.<br /> <br /> This type of use case is documented to cause undefined behavior, so<br /> returning EIO error for the copy up makes sense, but it should not be<br /> causing a WARN_ON assertion.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: ensure offloading TID queue exists<br /> <br /> The resume code path assumes that the TX queue for the offloading TID<br /> has been configured. At resume time it then tries to sync the write<br /> pointer as it may have been updated by the firmware.<br /> <br /> In the unusual event that no packets have been send on TID 0, the queue<br /> will not have been allocated and this causes a crash. Fix this by<br /> ensuring the queue exist at suspend time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: do not compare internal table flags on updates<br /> <br /> Restore skipping transaction if table update does not modify flags.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-mt65xx: Fix NULL pointer access in interrupt handler<br /> <br /> The TX buffer in spi_transfer can be a NULL pointer, so the interrupt<br /> handler may end up writing to the invalid memory and cause crashes.<br /> <br /> Add a check to trans-&gt;tx_buf before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix mmhub client id out-of-bounds access<br /> <br /> Properly handle cid 0x140.