Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: tw686x: Fix memory leak in tw686x_video_init<br /> <br /> video_device_alloc() allocates memory for vdev,<br /> when video_register_device() fails, it doesn&amp;#39;t release the memory and<br /> leads to memory leak, call video_device_release() to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mcde: Fix refcount leak in mcde_dsi_bind<br /> <br /> Every iteration of for_each_available_child_of_node() decrements<br /> the reference counter of the previous node. There is no decrement<br /> when break out from the loop and results in refcount leak.<br /> Add missing of_node_put() to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds<br /> <br /> Presently ima_get_kexec_buffer() doesn&amp;#39;t check if the previous kernel&amp;#39;s<br /> ima-kexec-buffer lies outside the addressable memory range. This can result<br /> in a kernel panic if the new kernel is booted with &amp;#39;mem=X&amp;#39; arg and the<br /> ima-kexec-buffer was allocated beyond that range by the previous kernel.<br /> The panic is usually of the form below:<br /> <br /> $ sudo kexec --initrd initrd vmlinux --append=&amp;#39;mem=16G&amp;#39;<br /> <br /> <br /> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000<br /> Faulting instruction address: 0xc000000000837974<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> <br /> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0<br /> LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160<br /> Call Trace:<br /> [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160<br /> [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108<br /> [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120<br /> [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0<br /> [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec<br /> [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0<br /> [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64<br /> Instruction dump:<br /> f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330<br /> 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Fix this issue by checking returned PFN range of previous kernel&amp;#39;s<br /> ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: maps: Fix refcount leak in ap_flash_init<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: maps: Fix refcount leak in of_flash_probe_versatile<br /> <br /> of_find_matching_node_and_match() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: libertas: Fix possible refcount leak in if_usb_probe()<br /> <br /> usb_get_dev will be called before lbs_get_firmware_async which means that<br /> usb_put_dev need to be called when lbs_get_firmware_async fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: fix incorrect dev_tracker usage<br /> <br /> While investigating a separate rose issue [1], and enabling<br /> CONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reported an orthogonal ax25 issue [2]<br /> <br /> An ax25_dev can be used by one (or many) struct ax25_cb.<br /> We thus need different dev_tracker, one per struct ax25_cb.<br /> <br /> After this patch is applied, we are able to focus on rose.<br /> <br /> [1] https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/<br /> <br /> [2]<br /> [ 205.798723] reference already released.<br /> [ 205.798732] allocated in:<br /> [ 205.798734] ax25_bind+0x1a2/0x230 [ax25]<br /> [ 205.798747] __sys_bind+0xea/0x110<br /> [ 205.798753] __x64_sys_bind+0x18/0x20<br /> [ 205.798758] do_syscall_64+0x5c/0x80<br /> [ 205.798763] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 205.798768] freed in:<br /> [ 205.798770] ax25_release+0x115/0x370 [ax25]<br /> [ 205.798778] __sock_release+0x42/0xb0<br /> [ 205.798782] sock_close+0x15/0x20<br /> [ 205.798785] __fput+0x9f/0x260<br /> [ 205.798789] ____fput+0xe/0x10<br /> [ 205.798792] task_work_run+0x64/0xa0<br /> [ 205.798798] exit_to_user_mode_prepare+0x18b/0x190<br /> [ 205.798804] syscall_exit_to_user_mode+0x26/0x40<br /> [ 205.798808] do_syscall_64+0x69/0x80<br /> [ 205.798812] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 205.798827] ------------[ cut here ]------------<br /> [ 205.798829] WARNING: CPU: 2 PID: 2605 at lib/ref_tracker.c:136 ref_tracker_free.cold+0x60/0x81<br /> [ 205.798837] Modules linked in: rose netrom mkiss ax25 rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_hda_codec_hdmi nls_iso8859_1 i915 rtw88_8821ce rtw88_8821c x86_pkg_temp_thermal rtw88_pci intel_powerclamp rtw88_core snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp snd_hda_intel kvm_intel snd_intel_dspcfg mac80211 snd_hda_codec kvm i2c_algo_bit drm_buddy drm_dp_helper btusb drm_kms_helper snd_hwdep btrtl snd_hda_core btbcm joydev crct10dif_pclmul btintel crc32_pclmul ghash_clmulni_intel mei_hdcp btmtk intel_rapl_msr aesni_intel bluetooth input_leds snd_pcm crypto_simd syscopyarea processor_thermal_device_pci_legacy sysfillrect cryptd intel_soc_dts_iosf snd_seq sysimgblt ecdh_generic fb_sys_fops rapl libarc4 processor_thermal_device intel_cstate processor_thermal_rfim cec snd_timer ecc snd_seq_device cfg80211 processor_thermal_mbox mei_me processor_thermal_rapl mei rc_core at24 snd intel_pch_thermal intel_rapl_common ttm soundcore int340x_thermal_zone video<br /> [ 205.798948] mac_hid acpi_pad sch_fq_codel ipmi_devintf ipmi_msghandler drm msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 hid_generic usbhid hid i2c_i801 i2c_smbus r8169 xhci_pci ahci libahci realtek lpc_ich xhci_pci_renesas [last unloaded: ax25]<br /> [ 205.798992] CPU: 2 PID: 2605 Comm: ax25ipd Not tainted 5.18.11-F6BVP #3<br /> [ 205.798996] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020<br /> [ 205.798999] RIP: 0010:ref_tracker_free.cold+0x60/0x81<br /> [ 205.799005] Code: e8 d2 01 9b ff 83 7b 18 00 74 14 48 c7 c7 2f d7 ff 98 e8 10 6e fc ff 8b 7b 18 e8 b8 01 9b ff 4c 89 ee 4c 89 e7 e8 5d fd 07 00 0b b8 ea ff ff ff e9 30 05 9b ff 41 0f b6 f7 48 c7 c7 a0 fa 4e<br /> [ 205.799008] RSP: 0018:ffffaf5281073958 EFLAGS: 00010286<br /> [ 205.799011] RAX: 0000000080000000 RBX: ffff9a0bd687ebe0 RCX: 0000000000000000<br /> [ 205.799014] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 00000000ffffffff<br /> [ 205.799016] RBP: ffffaf5281073a10 R08: 0000000000000003 R09: fffffffffffd5618<br /> [ 205.799019] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff9a0bc53384d0<br /> [ 205.799022] R13: 0000000000000282 R14: 00000000ae000001 R15: 0000000000000001<br /> [ 205.799024] FS: 0000000000000000(0000) GS:ffff9a0d0f300000(0000) knlGS:0000000000000000<br /> [ 205.799028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 205.799031] CR2: 00007ff6b8311554 CR3: 000000001ac10004 CR4: 00000000001706e0<br /> [ 205.799033] Call Trace:<br /> [ 205.799035] <br /> [ 205.799038] ? ax25_dev_device_down+0xd9/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix double list_add at iwl_mvm_mac_wake_tx_queue<br /> <br /> After successfull station association, if station queues are disabled for<br /> some reason, the related lists are not emptied. So if some new element is<br /> added to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old<br /> one and produce a BUG like this:<br /> <br /> [ 46.535263] list_add corruption. prev-&gt;next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388).<br /> [ 46.535283] ------------[ cut here ]------------<br /> [ 46.535284] kernel BUG at lib/list_debug.c:26!<br /> [ 46.535290] invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> [ 46.585304] CPU: 0 PID: 623 Comm: wpa_supplicant Not tainted 5.19.0-rc3+ #1<br /> [ 46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012<br /> [ 46.600336] RIP: 0010:__list_add_valid.cold+0x3d/0x3f<br /> [ 46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1<br /> [ 46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286<br /> [ 46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000<br /> [ 46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff<br /> [ 46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666<br /> [ 46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388<br /> [ 46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0<br /> [ 46.666108] FS: 00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000<br /> [ 46.674331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0<br /> [ 46.687422] Call Trace:<br /> [ 46.689906] <br /> [ 46.691950] iwl_mvm_mac_wake_tx_queue+0xec/0x15c [iwlmvm]<br /> [ 46.697601] ieee80211_queue_skb+0x4b3/0x720 [mac80211]<br /> [ 46.702973] ? sta_info_get+0x46/0x60 [mac80211]<br /> [ 46.707703] ieee80211_tx+0xad/0x110 [mac80211]<br /> [ 46.712355] __ieee80211_tx_skb_tid_band+0x71/0x90 [mac80211]<br /> ...<br /> <br /> In order to avoid this problem, we must also remove the related lists when<br /> station queues are disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wil6210: debugfs: fix uninitialized variable use in `wil_write_file_wmi()`<br /> <br /> Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user()<br /> but it forgets to change the value to be returned that came from<br /> simple_write_to_buffer() call. It results in the following warning:<br /> <br /> warning: variable &amp;#39;rc&amp;#39; is uninitialized when used here [-Wuninitialized]<br /> return rc;<br /> ^~<br /> <br /> Remove rc variable and just return the passed in length if the<br /> memdup_user() succeeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: When HCI work queue is drained, only queue chained work<br /> <br /> The HCI command, event, and data packet processing workqueue is drained<br /> to avoid deadlock in commit<br /> 76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").<br /> <br /> There is another delayed work, which will queue command to this drained<br /> workqueue. Which results in the following error report:<br /> <br /> Bluetooth: hci2: command 0x040f tx timeout<br /> WARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140<br /> Workqueue: events hci_cmd_timeout<br /> RIP: 0010:__queue_work+0xdad/0x1140<br /> RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093<br /> RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000<br /> RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08<br /> RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700<br /> R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60<br /> R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800<br /> FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? queue_work_on+0xcb/0x110<br /> ? lockdep_hardirqs_off+0x90/0xd0<br /> queue_work_on+0xee/0x110<br /> process_one_work+0x996/0x1610<br /> ? pwq_dec_nr_in_flight+0x2a0/0x2a0<br /> ? rwlock_bug.part.0+0x90/0x90<br /> ? _raw_spin_lock_irq+0x41/0x50<br /> worker_thread+0x665/0x1080<br /> ? process_one_work+0x1610/0x1610<br /> kthread+0x2e9/0x3a0<br /> ? kthread_complete_and_exit+0x40/0x40<br /> ret_from_fork+0x1f/0x30<br /> <br /> <br /> To fix this, we can add a new HCI_DRAIN_WQ flag, and don&amp;#39;t queue the<br /> timeout workqueue while command workqueue is draining.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: fix random warning message when driver load<br /> <br /> Warning log:<br /> [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code!<br /> [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20<br /> [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT)<br /> [ 4.163155] Call trace:<br /> [ 4.165600] dump_backtrace+0x0/0x1b0<br /> [ 4.169286] show_stack+0x18/0x68<br /> [ 4.172611] dump_stack_lvl+0x68/0x84<br /> [ 4.176286] dump_stack+0x18/0x34<br /> [ 4.179613] kmalloc_fix_flags+0x60/0x88<br /> [ 4.183550] new_slab+0x334/0x370<br /> [ 4.186878] ___slab_alloc.part.108+0x4d4/0x748<br /> [ 4.191419] __slab_alloc.isra.109+0x30/0x78<br /> [ 4.195702] kmem_cache_alloc+0x40c/0x420<br /> [ 4.199725] dma_pool_alloc+0xac/0x1f8<br /> [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0<br /> <br /> pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)<br /> {<br /> ...<br /> page = kmalloc(sizeof(*page), mem_flags);<br /> page-&gt;vaddr = dma_alloc_coherent(pool-&gt;dev, pool-&gt;allocation,<br /> &amp;page-&gt;dma, mem_flags);<br /> ...<br /> }<br /> <br /> kmalloc was called with mem_flags, which is passed down in<br /> cdns3_allocate_trb_pool() and have GFP_DMA32 flags.<br /> kmall_fix_flags() report warning.<br /> <br /> GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle<br /> DMA memory region correctly by pool-&gt;dev. GFP_DMA32 can be removed<br /> safely.