ALT-BU-2022-4621-9
Branch p9 update bulletin.
Package kernel-image-un-def updated to version 5.10.111-alt1 for branch p9 in task 298409.
Closed vulnerabilities
Modified: 2026-01-20
BDU:2022-02367
Уязвимость ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-09-30
BDU:2022-05844
Уязвимость функции diFree (fs/jfs/inode.c) журналируемой файловой системы (JFS) ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию или вызвать отказ в обслуживании
BDU:2025-04429
Уязвимость функции hfi1_mmu_rb_unregister() модуля drivers/infiniband/hw/hfi1/mmu_rb.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-06039
Уязвимость функции virt_addr_valid() модуля arch/powerpc/include/asm/page.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06043
Уязвимость функций gpiochip_to_irq() и gpiochip_add_irqchip() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06044
Уязвимость функции SATA_DWC_QCMD_MAX() модуля drivers/ata/sata_dwc_460ex.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06045
Уязвимость функций gic_dist_base() и gic_do_wait_for_rwp() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06049
Уязвимость модуля fs/btrfs/extent_io.h файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
BDU:2025-06051
Уязвимость модуля mm/mremap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06058
Уязвимость функции qede_build_skb() модуля drivers/net/ethernet/qlogic/qede/qede_fp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06059
Уязвимость функций dpaa2_ptp_probe() и fsl_mc_free_irqs() модуля drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06060
Уязвимость функции spin_lock_irqsave() модуля drivers/infiniband/sw/rdmavt/qp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06062
Уязвимость функции omap_iommu_probe_device() модуля drivers/iommu/omap-iommu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06063
Уязвимость функции kmem_cache_alloc() модуля mm/mempolicy.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06065
Уязвимость функций nla_alloc_flow_actions() и ovs_nla_free_set_action() модуля net/openvswitch/flow_netlink.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06552
Уязвимость функции rxrpc_exit_net() модуля net/rxrpc/net_ns.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-06553
Уязвимость функции LZ4_decompress_generic() модуля lib/lz4/lz4_decompress.c поддержки сжатия lz4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-06573
Уязвимость функции nla_put_notification_header() модуля drivers/block/drbd/drbd_nl.c - драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10262
Уязвимость функции hci_disconn_phylink_complete_evt() модуля net/bluetooth/hci_event.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2026-01253
Уязвимость функций init() и fini() модуля drivers/char/virtio_console.c драйвера поддержки алфавитноцифровых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01254
Уязвимость функции _nfs42_proc_copy_notify() модуля fs/nfs/nfs42proc.c поддержки клиентов NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01256
Уязвимость функции ill_acc_of_setup() модуля arch/mips/ralink/ill_acc.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01257
Уязвимость функции interrupt_preinit_v3_hw() модуля drivers/scsi/hisi_sas/hisi_sas_v3_hw.c драйвера поддержки устройств SCSI HiSilicon SAS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01258
Уязвимость функции pm8001_chip_fw_flash_update_req() модуля drivers/scsi/pm8001/pm8001_hwi.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01265
Уязвимость функции nfs_set_pgio_error() модуля fs/nfs/pagelist.c поддержки клиентов NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01465
Уязвимость функции lookup_ioctl() модуля drivers/md/dm-ioctl.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01491
Уязвимость функции fc_exch_abts_resp() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01547
Уязвимость функции pm8001_send_abort_all() модуля drivers/scsi/pm8001/pm8001_hwi.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01548
Уязвимость функции pm8001_chip_reg_dev_req() модуля drivers/scsi/pm8001/pm8001_hwi.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02250
Уязвимость функции ath5k_eeprom_convert_pcal_info_5111() модуля drivers/net/wireless/ath/ath5k/eeprom.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03102
Уязвимость функции format_show() модуля arch/powerpc/kernel/secvar-sysfs.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03654
Уязвимость функции imx_pd_connector_get_modes() модуля drivers/gpu/drm/imx/parallel-display.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03655
Уязвимость функции zorro7xx_remove_one() модуля drivers/scsi/zorro7xx.c драйвера поддержки устройств SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03844
Уязвимость функции vmbus_exit() модуля drivers/hv/vmbus_drv.c драйвера поддержки гостевого режима Microsoft HyperV ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03933
Уязвимость функции decrypt_internal() модуля net/tls/tls_sw.c реализации протокола TLS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-04062
Уязвимость функции fib_nh_match() модуля net/ipv4/fib_semantics.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2021-4197
An unprivileged write to the file handler flaw in the Linux kernel's control groups and namespaces subsystem was found in the way users have access to some less privileged process that are controlled by cgroups and have higher privileged parent process. It is actually both for cgroup2 and cgroup1 versions of control groups. A local user could use this flaw to crash the system or escalate their privileges on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2035652
- https://lore.kernel.org/lkml/20211209214707.805617-1-tj%40kernel.org/T/
- https://security.netapp.com/advisory/ntap-20220602-0006/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2035652
- https://lore.kernel.org/lkml/20211209214707.805617-1-tj%40kernel.org/T/
- https://security.netapp.com/advisory/ntap-20220602-0006/
- https://www.debian.org/security/2022/dsa-5127
- https://www.debian.org/security/2022/dsa-5173
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2025-09-23
CVE-2021-47633
In the Linux kernel, the following vulnerability has been resolved: ath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111 The bug was found during fuzzing. Stacktrace locates it in ath5k_eeprom_convert_pcal_info_5111. When none of the curve is selected in the loop, idx can go up to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound. pd = &chinfo[pier].pd_curves[idx]; There are many OOB writes using pd later in the code. So I added a sanity check for idx. Checks for other loops involving AR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not used outside the loops. The patch is NOT tested with real device. The following is the fuzzing report BUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] Write of size 1 at addr ffff8880174a4d60 by task modprobe/214 CPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] __kasan_report.cold+0x37/0x7c ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] kasan_report+0xe/0x20 ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k] ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k] ath5k_eeprom_init+0x2513/0x6290 [ath5k] ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k] ? usleep_range+0xb8/0x100 ? apic_timer_interrupt+0xa/0x20 ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k] ath5k_hw_init+0xb60/0x1970 [ath5k] ath5k_init_ah+0x6fe/0x2530 [ath5k] ? kasprintf+0xa6/0xe0 ? ath5k_stop+0x140/0x140 [ath5k] ? _dev_notice+0xf6/0xf6 ? apic_timer_interrupt+0xa/0x20 ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k] ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] ? mutex_lock+0x89/0xd0 ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 ? pci_device_remove+0x280/0x280 ? pci_device_remove+0x280/0x280 really_probe+0x209/0x5d0
- https://git.kernel.org/stable/c/25efc5d03455c3839249bc77fce5e29ecb54677e
- https://git.kernel.org/stable/c/564d4eceb97eaf381dd6ef6470b06377bb50c95a
- https://git.kernel.org/stable/c/9d7d83d0399e23d66fd431b553842a84ac10398f
- https://git.kernel.org/stable/c/be2f81024e7981565d90a4c9ca3067d11b6bca7f
- https://git.kernel.org/stable/c/c4e2f577271e158d87a916afb4e87415a88ce856
- https://git.kernel.org/stable/c/cbd96d6cad6625feba9c8d101ed4977d53e82f8e
- https://git.kernel.org/stable/c/ed3dfdaa8b5f0579eabfc1c5818eed30cfe1fe84
- https://git.kernel.org/stable/c/f4de974019a0adf34d0e7de6b86252f1bd266b06
- https://git.kernel.org/stable/c/fc8f7752a82f4accb99c0f1a868906ba1eb7b86f
Modified: 2024-11-21
CVE-2022-3202
A NULL pointer dereference flaw in diFree in fs/jfs/inode.c in Journaled File System (JFS)in the Linux kernel. This could allow a local attacker to crash the system or leak kernel internal information.
Modified: 2025-10-14
CVE-2022-49067
In the Linux kernel, the following vulnerability has been resolved: powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000. Because of the way __pa() works we have: __pa(0x8000000000000000) == 0, and therefore virt_to_pfn(0x8000000000000000) == 0, and therefore virt_addr_valid(0x8000000000000000) == true Which is wrong, virt_addr_valid() should be false for vmalloc space. In fact all vmalloc addresses that alias with a valid PFN will return true from virt_addr_valid(). That can cause bugs with hardened usercopy as described below by Kefeng Wang: When running ethtool eth0 on 64-bit Book3E, a BUG occurred: usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)! kernel BUG at mm/usercopy.c:99 ... usercopy_abort+0x64/0xa0 (unreliable) __check_heap_object+0x168/0x190 __check_object_size+0x1a0/0x200 dev_ethtool+0x2494/0x2b20 dev_ioctl+0x5d0/0x770 sock_do_ioctl+0xf0/0x1d0 sock_ioctl+0x3ec/0x5a0 __se_sys_ioctl+0xf0/0x160 system_call_exception+0xfc/0x1f0 system_call_common+0xf8/0x200 The code shows below, data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true on 64-bit Book3E, which leads to the panic. As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in the virt_addr_valid() for 64-bit, also add upper limit check to make sure the virt is below high_memory. Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start of lowmem, high_memory is the upper low virtual address, the check is suitable for 32-bit, this will fix the issue mentioned in commit 602946ec2f90 ("powerpc: Set max_mapnr correctly") too. On 32-bit there is a similar problem with high memory, that was fixed in commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that commit breaks highmem and needs to be reverted. We can't easily fix __pa(), we have code that relies on its current behaviour. So for now add extra checks to virt_addr_valid(). For 64-bit Book3S the extra checks are not necessary, the combination of virt_to_pfn() and pfn_valid() should yield the correct result, but they are harmless. [mpe: Add additional change log detail]
- https://git.kernel.org/stable/c/a3727c25eacd7e437c4f560957fa3a376fe93e6b
- https://git.kernel.org/stable/c/cbc065efcba000ad8f615f506ebe61b6d3c5145b
- https://git.kernel.org/stable/c/d36febbcd537fcc50284e8b89609632d0146529f
- https://git.kernel.org/stable/c/deab81144d5a043f42804207fb76cfbd8a806978
- https://git.kernel.org/stable/c/fddb88bd266f4513abab7c36bca98935c9148a98
- https://git.kernel.org/stable/c/ffa0b64e3be58519ae472ea29a1a1ad681e32f48
Modified: 2025-09-23
CVE-2022-49072
In the Linux kernel, the following vulnerability has been resolved: gpio: Restrict usage of GPIO chip irq members before initialization GPIO chip irq members are exposed before they could be completely initialized and this leads to race conditions. One such issue was observed for the gc->irq.domain variable which was accessed through the I2C interface in gpiochip_to_irq() before it could be initialized by gpiochip_add_irqchip(). This resulted in Kernel NULL pointer dereference. Following are the logs for reference :- kernel: Call Trace: kernel: gpiod_to_irq+0x53/0x70 kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0 kernel: i2c_acpi_get_irq+0xc0/0xd0 kernel: i2c_device_probe+0x28a/0x2a0 kernel: really_probe+0xf2/0x460 kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0 To avoid such scenarios, restrict usage of GPIO chip irq members before they are completely initialized.
- https://git.kernel.org/stable/c/0912cf021fb5749372b3782611d8b1de4986c13a
- https://git.kernel.org/stable/c/2c1fa3614795e2b24da1ba95de0b27b8f6ea4537
- https://git.kernel.org/stable/c/5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320
- https://git.kernel.org/stable/c/7e88a50704b0c49ad3f2d11e8b963341cf68a89f
- https://git.kernel.org/stable/c/f8dea54f74cae8c2e4d7b2952e8fed7743a85c87
Modified: 2025-09-23
CVE-2022-49073
In the Linux kernel, the following vulnerability has been resolved:
ata: sata_dwc_460ex: Fix crash due to OOB write
the driver uses libata's "tag" values from in various arrays.
Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,
the value of the SATA_DWC_QCMD_MAX needs to account for that.
Otherwise ATA_TAG_INTERNAL usage cause similar crashes like
this as reported by Tice Rex on the OpenWrt Forum and
reproduced (with symbols) here:
| BUG: Kernel NULL pointer dereference at 0x00000000
| Faulting instruction address: 0xc03ed4b8
| Oops: Kernel access of bad area, sig: 11 [#1]
| BE PAGE_SIZE=4K PowerPC 44x Platform
| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0
| NIP: c03ed4b8 LR: c03d27e8 CTR: c03ed36c
| REGS: cfa59950 TRAP: 0300 Not tainted (5.4.163)
| MSR: 00021000
- https://git.kernel.org/stable/c/234c0132f76f0676d175757f61b0025191a3d935
- https://git.kernel.org/stable/c/3a8751c0d4e24129e72dcec0139e99833b13904a
- https://git.kernel.org/stable/c/55e1465ba79562a191708a40eeae3f8082a209e3
- https://git.kernel.org/stable/c/596c7efd69aae94f4b0e91172b075eb197958b99
- https://git.kernel.org/stable/c/7aa8104a554713b685db729e66511b93d989dd6a
- https://git.kernel.org/stable/c/8a05a6952ecd59aaa62cbdcdaf523ae2c8f436e8
- https://git.kernel.org/stable/c/fc629224aa62f23849cae83717932985ac51232d
Modified: 2025-10-14
CVE-2022-49074
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix GICR_CTLR.RWP polling It turns out that our polling of RWP is totally wrong when checking for it in the redistributors, as we test the *distributor* bit index, whereas it is a different bit number in the RDs... Oopsie boo. This is embarassing. Not only because it is wrong, but also because it took *8 years* to notice the blunder... Just fix the damn thing.
- https://git.kernel.org/stable/c/0df6664531a12cdd8fc873f0cac0dcb40243d3e9
- https://git.kernel.org/stable/c/3c07cc242baf83f0bddbbd9d7945d0bee56d8b57
- https://git.kernel.org/stable/c/60e1eb4811f53f5f60c788297d978515e7a2637a
- https://git.kernel.org/stable/c/6fef3e3179e6ed8fecdd004ede541674ffa7749d
- https://git.kernel.org/stable/c/7218a789abb3e033f5f3a85636ca50d9ae7b0fc9
- https://git.kernel.org/stable/c/c7daf1b4ad809692d5c26f33c02ed8a031066548
- https://git.kernel.org/stable/c/ff24114bb08d8b90edf2aff0a4fd0689523e6c17
Modified: 2025-09-23
CVE-2022-49075
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix qgroup reserve overflow the qgroup limit We use extent_changeset->bytes_changed in qgroup_reserve_data() to record how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the bytes_changed is set as "unsigned int", and it will overflow if we try to fallocate a range larger than 4GiB. The result is we reserve less bytes and eventually break the qgroup limit. Unlike regular buffered/direct write, which we use one changeset for each ordered extent, which can never be larger than 256M. For fallocate, we use one changeset for the whole range, thus it no longer respects the 256M per extent limit, and caused the problem. The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNT When running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiB Since we have no control of how bytes_changed is used, it's better to set it to u64.
- https://git.kernel.org/stable/c/0355387ea5b02d353c9415613fab908fac5c52a6
- https://git.kernel.org/stable/c/44277c50fdba5019ca25bfad1b71e2561b0de11b
- https://git.kernel.org/stable/c/4b98799e181b4326a613108cf37acc1f55d21b45
- https://git.kernel.org/stable/c/6bfff81286d4491f02dad7814bae5c77c9ad2320
- https://git.kernel.org/stable/c/7941b74ed49b6db25efbef2256ebef843c11a010
- https://git.kernel.org/stable/c/82ae73ac963cee877ce34f7c31b2b456b516e96c
- https://git.kernel.org/stable/c/b642b52d0b50f4d398cb4293f64992d0eed2e2ce
- https://git.kernel.org/stable/c/f3d97b22a708bf9e3f3ac2ba232bcefd0b0c136b
Modified: 2025-03-24
CVE-2022-49076
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix use-after-free bug for mm struct Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may represent the last reference held on the task mm. hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed before the final use in hfi1_release_user_pages(). A new task may allocate the mm structure while it is still being used, resulting in problems. One manifestation is corruption of the mmap_sem counter leading to a hang in down_write(). Another is corruption of an mm struct that is in use by another task.
- https://git.kernel.org/stable/c/0b7186d657ee55e2cdefae498f07d5c1961e8023
- https://git.kernel.org/stable/c/2bbac98d0930e8161b1957dc0ec99de39ade1b3c
- https://git.kernel.org/stable/c/5a9a1b24ddb510715f8f621263938186579a965c
- https://git.kernel.org/stable/c/5f54364ff6cfcd14cddf5441c4a490bb28dd69f7
- https://git.kernel.org/stable/c/9ca11bd8222a612de0d2f54d050bfcf61ae2883f
Modified: 2025-10-14
CVE-2022-49077
In the Linux kernel, the following vulnerability has been resolved: mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0) If an mremap() syscall with old_size=0 ends up in move_page_tables(), it will call invalidate_range_start()/invalidate_range_end() unnecessarily, i.e. with an empty range. This causes a WARN in KVM's mmu_notifier. In the past, empty ranges have been diagnosed to be off-by-one bugs, hence the WARNing. Given the low (so far) number of unique reports, the benefits of detecting more buggy callers seem to outweigh the cost of having to fix cases such as this one, where userspace is doing something silly. In this particular case, an early return from move_page_tables() is enough to fix the issue.
- https://git.kernel.org/stable/c/01e67e04c28170c47700c2c226d732bbfedb1ad0
- https://git.kernel.org/stable/c/04bc13dae4a27b8d030843c85ae452bb2f1d9c1f
- https://git.kernel.org/stable/c/2358aa84ef6dafcf544a557caaa6b91afb4a0bd2
- https://git.kernel.org/stable/c/7d659cb1763ff17d1c6ee082fa6feb4267c7a30b
- https://git.kernel.org/stable/c/a04cb99c5d4668fe3f5c0e5b6da1cecd34c3f219
- https://git.kernel.org/stable/c/a05540f3903bd8295e8c4cd90dd3d416239a115b
- https://git.kernel.org/stable/c/c19d8de4e682ec4b0ea2b04a832cd8cc0be3bb31
- https://git.kernel.org/stable/c/e2c328c2a8f9de8b761bd4025b66c63120c55761
- https://git.kernel.org/stable/c/eeaf28e2a0128147d687237e59d5407ee1b14693
Modified: 2025-12-19
CVE-2022-49078
In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/
- https://git.kernel.org/stable/c/467d5e200ab4486b744fe1776154a43d1aa22d4b
- https://git.kernel.org/stable/c/6adc01a7aa37445dafe8846faa0610a86029b253
- https://git.kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3
- https://git.kernel.org/stable/c/9fb8bc6cfc58773ce95414e11c9ccc8fc6ac4927
- https://git.kernel.org/stable/c/e64dbe97c05c769525cbca099ddbd22485630235
- https://git.kernel.org/stable/c/eafc0a02391b7b36617b36c97c4b5d6832cf5e24
Modified: 2025-09-23
CVE-2022-49080
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix mpol_new leak in shared_policy_replace If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation. This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }
- https://git.kernel.org/stable/c/198932a14aeb19a15cf19e51e151d023bc4cd648
- https://git.kernel.org/stable/c/25f506273b6ae806fd46bfcb6fdaa5b9ec81a05b
- https://git.kernel.org/stable/c/39a32f3c06f6d68a530bf9612afa19f50f12e93d
- https://git.kernel.org/stable/c/4ad099559b00ac01c3726e5c95dc3108ef47d03e
- https://git.kernel.org/stable/c/5e16dc5378abd749a836daa9ee4ab2c8d2668999
- https://git.kernel.org/stable/c/6e00309ac716fa8225f0cbde2cd9c24f0e74ee21
- https://git.kernel.org/stable/c/8510c2346d9e47a72b7f018a36ef0c39483e53d6
- https://git.kernel.org/stable/c/f7e183b0a7136b6dc9c7b9b2a85a608a8feba894
- https://git.kernel.org/stable/c/fe39ac59dbbf893b73b24e3184161d0bd06d6651
Modified: 2025-09-23
CVE-2022-49083
In the Linux kernel, the following vulnerability has been resolved:
iommu/omap: Fix regression in probe for NULL pointer dereference
Commit 3f6634d997db ("iommu: Use right way to retrieve iommu_ops") started
triggering a NULL pointer dereference for some omap variants:
__iommu_probe_device from probe_iommu_group+0x2c/0x38
probe_iommu_group from bus_for_each_dev+0x74/0xbc
bus_for_each_dev from bus_iommu_probe+0x34/0x2e8
bus_iommu_probe from bus_set_iommu+0x80/0xc8
bus_set_iommu from omap_iommu_init+0x88/0xcc
omap_iommu_init from do_one_initcall+0x44/0x24
This is caused by omap iommu probe returning 0 instead of ERR_PTR(-ENODEV)
as noted by Jason Gunthorpe
- https://git.kernel.org/stable/c/1d89f2b9eadbcf3ce93c6d7238f68299a1f84968
- https://git.kernel.org/stable/c/47e239117bd97c8556f9187af7a9a7938db4e021
- https://git.kernel.org/stable/c/71ff461c3f41f6465434b9e980c01782763e7ad8
- https://git.kernel.org/stable/c/bd905fed87ce01ac010011bb8f44ed0140116ceb
- https://git.kernel.org/stable/c/ea518578aa8a9a0280605b53cc33f707e10c8178
Modified: 2025-09-23
CVE-2022-49084
In the Linux kernel, the following vulnerability has been resolved: qede: confirm skb is allocated before using qede_build_skb() assumes build_skb() always works and goes straight to skb_reserve(). However, build_skb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL. Add a check in case build_skb() failed to allocate and return NULL. The NULL return is handled correctly in callers to qede_build_skb().
- https://git.kernel.org/stable/c/034a92c6a81048128fc7b18d278d52438a13902a
- https://git.kernel.org/stable/c/4e910dbe36508654a896d5735b318c0b88172570
- https://git.kernel.org/stable/c/8928239e5e2e460d95b8a0b89f61671625e7ece0
- https://git.kernel.org/stable/c/9648adb1b3ece55c657d3a4f52bfee663b710dfe
- https://git.kernel.org/stable/c/b2d6b3db9d1cf80908964036dbe1c52a86b1afb1
- https://git.kernel.org/stable/c/c9bdce2359b5f4986eb38d1e81865b3586cc20d2
- https://git.kernel.org/stable/c/e1fd0c42acfa22bb34d2ab6a111484f466ab8093
Modified: 2025-03-25
CVE-2022-49085
In the Linux kernel, the following vulnerability has been resolved: drbd: Fix five use after free bugs in get_initial_state In get_initial_state, it calls notify_initial_state_done(skb,..) if cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(), the skb will be freed by nlmsg_free(skb). Then get_initial_state will goto out and the freed skb will be used by return value skb->len, which is a uaf bug. What's worse, the same problem goes even further: skb can also be freed in the notify_*_state_change -> notify_*_state calls below. Thus 4 additional uaf bugs happened. My patch lets the problem callee functions: notify_initial_state_done and notify_*_state_change return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid. v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/
- https://git.kernel.org/stable/c/0489700bfeb1e53eb2039c2291c67e71b0b40103
- https://git.kernel.org/stable/c/188fe6b26765edbad4055611c0f788b6870f4024
- https://git.kernel.org/stable/c/226e993c39405292781bfcf4b039a8db56aab362
- https://git.kernel.org/stable/c/594205b4936771a250f9d141e7e0fff21c3dd2d9
- https://git.kernel.org/stable/c/a972c768723359ec995579902473028fe3cd64b1
- https://git.kernel.org/stable/c/aadb22ba2f656581b2f733deb3a467c48cc618f6
- https://git.kernel.org/stable/c/b6a4055036eed1f5e239ce3d8b0db1ce38bba447
- https://git.kernel.org/stable/c/dcf6be17b5c53b741898d2223b23e66d682de300
- https://git.kernel.org/stable/c/de63e74da2333b4068bb79983e632db730fea97e
Modified: 2025-09-23
CVE-2022-49086
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0) Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too.
- https://git.kernel.org/stable/c/1f30fb9166d4f15a1aa19449b9da871fe0ed4796
- https://git.kernel.org/stable/c/3554c214b83ec9a839ed574263a34218f372990c
- https://git.kernel.org/stable/c/53bce9d19b0a9d245b25cd050b81652ed974a509
- https://git.kernel.org/stable/c/5ae05b5eb58773cfec307ff88aff4cfd843c4cff
- https://git.kernel.org/stable/c/7438dc55c0709819b813f4778aec2c48b782990b
- https://git.kernel.org/stable/c/837b96d8103938e35e7d92cd9db96af914ca4fff
- https://git.kernel.org/stable/c/ef6f9ce0a79aa23b10fc5f3b3cab3814a25aac40
Modified: 2025-03-25
CVE-2022-49087
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: fix a race in rxrpc_exit_net()
Current code can lead to the following race:
CPU0 CPU1
rxrpc_exit_net()
rxrpc_peer_keepalive_worker()
if (rxnet->live)
rxnet->live = false;
del_timer_sync(&rxnet->peer_keepalive_timer);
timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);
cancel_work_sync(&rxnet->peer_keepalive_work);
rxrpc_exit_net() exits while peer_keepalive_timer is still armed,
leading to use-after-free.
syzbot report was:
ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0
WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Modules linked in:
CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505
Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3
RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0
R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/08ff0e74fab517dbc44e11b8bc683dd4ecc65950
- https://git.kernel.org/stable/c/1946014ca3b19be9e485e780e862c375c6f98bad
- https://git.kernel.org/stable/c/41024a40f6c793abbb916a857f18fb009f07464c
- https://git.kernel.org/stable/c/571d8e1d154ca18f08dcb72b69318d36e10010a0
- https://git.kernel.org/stable/c/7ee84d29f22de6f6c63fad6c54690517659862f1
- https://git.kernel.org/stable/c/864297ee30727ae6233f80296b7fc91442620b05
- https://git.kernel.org/stable/c/cd8aef1f30d1215648e4e6686cfb422004851429
Modified: 2025-09-23
CVE-2022-49088
In the Linux kernel, the following vulnerability has been resolved: dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak.
- https://git.kernel.org/stable/c/2b04bd4f03bba021959ca339314f6739710f0954
- https://git.kernel.org/stable/c/45fdd98b70142521739615ad1bfb760401863b73
- https://git.kernel.org/stable/c/46d120f7c163706d6c31ee00baa0be64c4572b78
- https://git.kernel.org/stable/c/599874bbc4ed832ccb578d48ac0ae7344382ef43
- https://git.kernel.org/stable/c/ebd1e3458dbf6643aa0272da398cb5b537d492b7
- https://git.kernel.org/stable/c/fbe5f4c0dd3475178f17ddd8b8d5044ebeae0be7
Modified: 2025-09-23
CVE-2022-49089
In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition.
- https://git.kernel.org/stable/c/43c2d7890ecabe527448a6c391fb2d9a5e6bbfe0
- https://git.kernel.org/stable/c/4d809f69695d4e7d1378b3a072fa9aef23123018
- https://git.kernel.org/stable/c/57800cc36e55db0547461c49acf5cd84c0f502b0
- https://git.kernel.org/stable/c/77ffb2495a41098f9d6a14f8aefde3188da75944
- https://git.kernel.org/stable/c/8a50937227c385a477177c9ffa122b4230e40666
- https://git.kernel.org/stable/c/92f1947c0d26060e978b3a9f21f32ce7c8c9cca3
Modified: 2025-09-23
CVE-2022-49091
In the Linux kernel, the following vulnerability has been resolved: drm/imx: Fix memory leak in imx_pd_connector_get_modes Avoid leaking the display mode variable if of_get_drm_display_mode fails. Addresses-Coverity-ID: 1443943 ("Resource leak")
- https://git.kernel.org/stable/c/31e449302ed00c38d4068443cf0243279701ab28
- https://git.kernel.org/stable/c/38bf605bd8c83d942c8dcffaef3633b7d8b37549
- https://git.kernel.org/stable/c/41624d7c0c3df71dee170c610744aaa5909327b8
- https://git.kernel.org/stable/c/7526102d908ec5ae777aa77723d52fce12916093
- https://git.kernel.org/stable/c/bc23c327e1a23cc3555fa1e86288e13288515442
- https://git.kernel.org/stable/c/bce81feb03a20fca7bbdd1c4af16b4e9d5c0e1d3
- https://git.kernel.org/stable/c/c539a6a5896ed92bfb91494e46996d013f3d5967
- https://git.kernel.org/stable/c/d2c2758cfb0262637fd93350bdc8ad485fb1dd61
- https://git.kernel.org/stable/c/f8b0ef0a5889890b50482b6593bd8de544736351
Modified: 2025-10-14
CVE-2022-49092
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: fix route with nexthop object delete warning
FRR folks have hit a kernel warning[1] while deleting routes[2] which is
caused by trying to delete a route pointing to a nexthop id without
specifying nhid but matching on an interface. That is, a route is found
but we hit a warning while matching it. The warning is from
fib_info_nh() in include/net/nexthop.h because we run it on a fib_info
with nexthop object. The call chain is:
inet_rtm_delroute -> fib_table_delete -> fib_nh_match (called with a
nexthop fib_info and also with fc_oif set thus calling fib_info_nh on
the fib_info and triggering the warning). The fix is to not do any
matching in that branch if the fi has a nexthop object because those are
managed separately. I.e. we should match when deleting without nh spec and
should fail when deleting a nexthop route with old-style nh spec because
nexthop objects are managed separately, e.g.:
$ ip r show 1.2.3.4/32
1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0
$ ip r del 1.2.3.4/32
$ ip r del 1.2.3.4/32 nhid 12
- https://git.kernel.org/stable/c/63ea57478aaa3e06a597081a0f537318fc04e49f
- https://git.kernel.org/stable/c/6bf92d70e690b7ff12b24f4bfff5e5434d019b82
- https://git.kernel.org/stable/c/907c97986d6fa77318d17659dd76c94b65dd27c5
- https://git.kernel.org/stable/c/dcd689f9e2640c992f94eae9955b106f71c6825d
- https://git.kernel.org/stable/c/f5064531c23ad646da7be8b938292b00a7e61438
- https://git.kernel.org/stable/c/f8db5743d09523c0bb35f16e13691e3b7eb5dba0
Modified: 2025-09-23
CVE-2022-49094
In the Linux kernel, the following vulnerability has been resolved:
net/tls: fix slab-out-of-bounds bug in decrypt_internal
The memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting in
tls_set_sw_offload(). The return value of crypto_aead_ivsize()
for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes
memory space will trigger slab-out-of-bounds bug as following:
==================================================================
BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]
Read of size 16 at addr ffff888114e84e60 by task tls/10911
Call Trace:
- https://git.kernel.org/stable/c/2304660ab6c425df64d95301b601424c6a50f28b
- https://git.kernel.org/stable/c/29be1816cbab9a0dc6243120939fd10a92753756
- https://git.kernel.org/stable/c/2b7d14c105dd8f6412eda5a91e1e6154653731e3
- https://git.kernel.org/stable/c/589154d0f18945f41d138a5b4e49e518d294474b
- https://git.kernel.org/stable/c/6e2f1b033b17dedda51d465861b69e58317d6343
- https://git.kernel.org/stable/c/9381fe8c849cfbe50245ac01fc077554f6eaa0e2
Modified: 2025-09-23
CVE-2022-49095
In the Linux kernel, the following vulnerability has been resolved: scsi: zorro7xx: Fix a resource leak in zorro7xx_remove_one() The error handling path of the probe releases a resource that is not freed in the remove function. In some cases, a ioremap() must be undone. Add the missing iounmap() call in the remove function.
- https://git.kernel.org/stable/c/16ed828b872d12ccba8f07bcc446ae89ba662f9c
- https://git.kernel.org/stable/c/1e0c01319dedf1e63ec5df37ead048e17afd92ba
- https://git.kernel.org/stable/c/34a47f7ddb4fd1cbd12397aa6f7dad1de08b4050
- https://git.kernel.org/stable/c/a845c678e094894f38cc9526d212b21933ce44c7
- https://git.kernel.org/stable/c/aefd755a96051aa56b198cb7ecd168b22ba384f6
- https://git.kernel.org/stable/c/c5f77b595379b5191316edd365a542f8b1526066
- https://git.kernel.org/stable/c/ce430cfad6a5385d5b7f7c1dc3fa50f10abfd41b
- https://git.kernel.org/stable/c/db863ab2baf058ed05c7b723612e3c40c9dd6885
- https://git.kernel.org/stable/c/de6aee0978f164d3d0c771ce03e3066a26c371c5
Modified: 2025-09-23
CVE-2022-49097
In the Linux kernel, the following vulnerability has been resolved: NFS: Avoid writeback threads getting stuck in mempool_alloc() In a low memory situation, allow the NFS writeback code to fail without getting stuck in infinite loops in mempool_alloc().
- https://git.kernel.org/stable/c/0bae835b63c53f86cdc524f5962e39409585b22c
- https://git.kernel.org/stable/c/1b3fa9a3c420c31e77b406ddc28f3a627100516c
- https://git.kernel.org/stable/c/a6caeddd68977a1aaaf62fbd1955b41dd5c3c5d3
- https://git.kernel.org/stable/c/c74e2f6ecc51bd08bb5b0335477dba954a50592e
- https://git.kernel.org/stable/c/ea029e4ce760f786919d06ef52efa2e50ea92a5f
Modified: 2025-10-14
CVE-2022-49098
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Fix potential crash on module unload The vmbus driver relies on the panic notifier infrastructure to perform some operations when a panic event is detected. Since vmbus can be built as module, it is required that the driver handles both registering and unregistering such panic notifier callback. After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback") though, the panic notifier registration is done unconditionally in the module initialization routine whereas the unregistering procedure is conditionally guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability is set. This patch fixes that by unconditionally unregistering the panic notifier in the module's exit routine as well.
- https://git.kernel.org/stable/c/2133c422a103cf7c7768c37b9ac382e73b691892
- https://git.kernel.org/stable/c/3d0078f8bddd58d9bb1ad40bbe929f8633abb276
- https://git.kernel.org/stable/c/5ea98d0f5f035c1bcf1517ccec0e024ae35a48b2
- https://git.kernel.org/stable/c/6b4c0149a56147b29169e07000d566162892722a
- https://git.kernel.org/stable/c/792f232d57ff28bbd5f9c4abe0466b23d5879dc8
- https://git.kernel.org/stable/c/cf580d2e3884dbafd6b90269b03a24d661578624
- https://git.kernel.org/stable/c/dcd6b1a624c0ffa21034d8b1e02e9d068458f596
Modified: 2025-10-14
CVE-2022-49100
In the Linux kernel, the following vulnerability has been resolved: virtio_console: eliminate anonymous module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs
- https://git.kernel.org/stable/c/0f3d824bd70a1303464d5e93ee3e7afe7832fe89
- https://git.kernel.org/stable/c/3504b0a177208eda85bf472bbf7c9aa77d2b8343
- https://git.kernel.org/stable/c/3fd5dee7404ce40c79cba468bb2510115639d975
- https://git.kernel.org/stable/c/44c2d5fbe7b2bd1f8cb114d608a591a73a5d4ae6
- https://git.kernel.org/stable/c/71612aee09ecea3475f8751dc841d75a011b1fd0
- https://git.kernel.org/stable/c/7deaddb704713608e0ae559e27185581b9af71a0
- https://git.kernel.org/stable/c/93e3d88321d2274fa4e26b006e19cc10fec331c2
- https://git.kernel.org/stable/c/c69b442125bf009fce26e15aa5616caf8a3673c3
- https://git.kernel.org/stable/c/fefb8a2a941338d871e2d83fbd65fbfa068857bd
Modified: 2025-10-01
CVE-2022-49103
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix reference count leaks in _nfs42_proc_copy_notify() [You don't often get email from xiongx18@fudan.edu.cn. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.] The reference counting issue happens in two error paths in the function _nfs42_proc_copy_notify(). In both error paths, the function simply returns the error code and forgets to balance the refcount of object `ctx`, bumped by get_nfs_open_context() earlier, which may cause refcount leaks. Fix it by balancing refcount of the `ctx` object before the function returns in both error paths.
- https://git.kernel.org/stable/c/9b9feec97c1fc7dd9bb69f62c4905cddf1801599
- https://git.kernel.org/stable/c/b37f482ba9f0e6382c188e3fccf6c4b2fdc938eb
- https://git.kernel.org/stable/c/b7f114edd54326f730a754547e7cfb197b5bc132
- https://git.kernel.org/stable/c/f46f632f9cfae4b2e3635fa58840a8ec584c42e3
- https://git.kernel.org/stable/c/fb73bf6305f4eb8f0cf9a61ee874d55f019d6dc4
Modified: 2025-10-01
CVE-2022-49104
In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_core: handle NULL result of find_service_by_handle In case of an invalid handle the function find_servive_by_handle returns NULL. So take care of this and avoid a NULL pointer dereference.
- https://git.kernel.org/stable/c/04202f54dd8899e10f56a89c4c1ede0043fa22af
- https://git.kernel.org/stable/c/3b424f6586a870b8d657c5e5419465bbe0e7b61f
- https://git.kernel.org/stable/c/42f2142a337ee372455574809fc924580a7e51b2
- https://git.kernel.org/stable/c/aa0b7296785312a4bfa8fac0ba8ad78698fd9fcf
- https://git.kernel.org/stable/c/ca225857faf237234d2fffe5d1919467dfadd822
Modified: 2025-10-01
CVE-2022-49105
In the Linux kernel, the following vulnerability has been resolved: staging: wfx: fix an error handling in wfx_init_common() One error handler of wfx_init_common() return without calling ieee80211_free_hw(hw), which may result in memory leak. And I add one err label to unify the error handler, which is useful for the subsequent changes.
- https://git.kernel.org/stable/c/60f1d3c92dc1ef1026e5b917a329a7fa947da036
- https://git.kernel.org/stable/c/86efcb524ae1889ae73f2a2f0bb7fff2ec757ab0
- https://git.kernel.org/stable/c/93498c6e775ae91732a8109dba1bdcd324908f84
- https://git.kernel.org/stable/c/9727912e906762a63c1a667c84731d3427653f88
- https://git.kernel.org/stable/c/ab0fed1fa744173433cfd1dbaf9239f200ded650
Modified: 2025-10-01
CVE-2022-49107
In the Linux kernel, the following vulnerability has been resolved: ceph: fix memory leak in ceph_readdir when note_last_dentry returns error Reset the last_readdir at the same time, and add a comment explaining why we don't free last_readdir when dir_emit returns false.
- https://git.kernel.org/stable/c/2fe82d3254029ef9ec4e7be890125d5ef4f537de
- https://git.kernel.org/stable/c/7f740ede35132d3d5d19747cad56a511d21bb156
- https://git.kernel.org/stable/c/e792575b902a3939ca482491ee9fb3a236f99640
- https://git.kernel.org/stable/c/f4429786129648a8f4bb1e5faa143c4478cc5c4a
- https://git.kernel.org/stable/c/f639d9867eea647005dc824e0e24f39ffc50d4e4
Modified: 2025-03-25
CVE-2022-49111
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use after free in hci_send_acl
This fixes the following trace caused by receiving
HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without
first checking if conn->type is in fact AMP_LINK and in case it is
do properly cleanup upper layers with hci_disconn_cfm:
==================================================================
BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50
Read of size 8 at addr ffff88800e404818 by task bluetoothd/142
CPU: 0 PID: 142 Comm: bluetoothd Not tainted
5.17.0-rc5-00006-gda4022eeac1a #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/2cc803804ec9a296b3156855d6c8c4ca1c6b84be
- https://git.kernel.org/stable/c/3803d896ddd97c7c16689a5381c0960040727647
- https://git.kernel.org/stable/c/4da302b90b96c309987eb9b37c8547f939f042d2
- https://git.kernel.org/stable/c/643a6c26bd32e339d00ad97b8822b6db009e803c
- https://git.kernel.org/stable/c/684e505406abaeabe0058e9776f9210bf2747953
- https://git.kernel.org/stable/c/b3c2ea1fd444b3bb7b82bfd2c3a45418f85c2502
- https://git.kernel.org/stable/c/c41de54b0a963e59e4dd04c029a4a6d73f45ef9c
- https://git.kernel.org/stable/c/d404765dffdbd8dcd14758695d0c96c52fb2e624
- https://git.kernel.org/stable/c/f63d24baff787e13b723d86fe036f84bdbc35045
Modified: 2025-10-01
CVE-2022-49113
In the Linux kernel, the following vulnerability has been resolved: powerpc/secvar: fix refcount leak in format_show() Refcount leak will happen when format_show returns failure in multiple cases. Unified management of of_node_put can fix this problem.
- https://git.kernel.org/stable/c/02222bf4f0a27f6eba66d1f597cdb5daadd51829
- https://git.kernel.org/stable/c/2a71e3ecd829a82013cf095c55068c61d991e885
- https://git.kernel.org/stable/c/c105ffb6b9744158e37e9f81f0f38861951d1c1f
- https://git.kernel.org/stable/c/d05e4265d33af60b39606c20c731e3e719bfe3d6
- https://git.kernel.org/stable/c/d601fd24e6964967f115f036a840f4f28488f63f
Modified: 2025-03-25
CVE-2022-49114
In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix use after free in fc_exch_abts_resp() fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free.
- https://git.kernel.org/stable/c/1d7effe5fff9d28e45e18ac3a564067c7ddfe898
- https://git.kernel.org/stable/c/271add11994ba1a334859069367e04d2be2ebdd4
- https://git.kernel.org/stable/c/412dd8299b02e4410fe77b8396953c1a8dde183a
- https://git.kernel.org/stable/c/499d198494e77b6533251b9b909baf5c101129cb
- https://git.kernel.org/stable/c/4a131d4ea8b581ac9b01d3a72754db4848be3232
- https://git.kernel.org/stable/c/5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836
- https://git.kernel.org/stable/c/6044ad64f41c87382cfeeca281573d1886d80cbe
- https://git.kernel.org/stable/c/87909291762d08fdb60d19069d7a89b5b308d0ef
- https://git.kernel.org/stable/c/f581df412bc45c95176e3c808ee2839c05b2ab0c
Modified: 2025-10-01
CVE-2022-49115
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix misused goto label Fix a misused goto label jump since that can result in a memory leak.
- https://git.kernel.org/stable/c/70236a0d2d62b081d52076de22d8d017d6cbe99f
- https://git.kernel.org/stable/c/7c657c0694ff690e361a13ce41c36b9dfb433ec8
- https://git.kernel.org/stable/c/bf8d87c076f55b8b4dfdb6bc6c6b6dc0c2ccb487
- https://git.kernel.org/stable/c/d3642fc64276b06446290f82fd45630aeaa4b007
- https://git.kernel.org/stable/c/dc9d33b2d8d09e6478e8ef817a81cf26930acc3e
Modified: 2025-10-01
CVE-2022-49116
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: use memset avoid memory leaks Use memset to initialize structs to prevent memory leaks in l2cap_ecred_connect
- https://git.kernel.org/stable/c/42b6a39f439b6f37cc2024d91ce547d83290ff78
- https://git.kernel.org/stable/c/9567d54e70ff58c2695c2cc2e53c86c67551d3e6
- https://git.kernel.org/stable/c/d3715b2333e9a21692ba16ef8645eda584a9515d
- https://git.kernel.org/stable/c/d588c183a971b85c775ad66da563ee6e8bc8158f
- https://git.kernel.org/stable/c/e9e55acee9b7a737ec7f5161b94a78932a5514c8
Modified: 2025-10-01
CVE-2022-49117
In the Linux kernel, the following vulnerability has been resolved: mips: ralink: fix a refcount leak in ill_acc_of_setup() of_node_put(np) needs to be called when pdev == NULL.
- https://git.kernel.org/stable/c/060a485df4ec1183d543317511cb4caa43468b5d
- https://git.kernel.org/stable/c/142ae7d4f21524acfe073e5a3da5667aa85eb970
- https://git.kernel.org/stable/c/4a0a1436053b17e50b7c88858fb0824326641793
- https://git.kernel.org/stable/c/5fb47ca3490813d3884d8ad0b2ce511aa3537551
- https://git.kernel.org/stable/c/8d7f7ef7980f287ace1c15f2ac03d6754e12f071
- https://git.kernel.org/stable/c/c74c755daed551b9aceb8388159180861474bdfe
Modified: 2025-10-15
CVE-2022-49118
In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Free irq vectors in order for v3 HW If the driver probe fails to request the channel IRQ or fatal IRQ, the driver will free the IRQ vectors before freeing the IRQs in free_irq(), and this will cause a kernel BUG like this: ------------[ cut here ]------------ kernel BUG at drivers/pci/msi.c:369! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: free_msi_irqs+0x118/0x13c pci_disable_msi+0xfc/0x120 pci_free_irq_vectors+0x24/0x3c hisi_sas_v3_probe+0x360/0x9d0 [hisi_sas_v3_hw] local_pci_probe+0x44/0xb0 work_for_cpu_fn+0x20/0x34 process_one_work+0x1d0/0x340 worker_thread+0x2e0/0x460 kthread+0x180/0x190 ret_from_fork+0x10/0x20 ---[ end trace b88990335b610c11 ]--- So we use devm_add_action() to control the order in which we free the vectors.
- https://git.kernel.org/stable/c/224903cc60d045576393c3b16907742f23e6c740
- https://git.kernel.org/stable/c/554fb72ee34f4732c7f694f56c3c6e67790352a0
- https://git.kernel.org/stable/c/8b6eab9d683bae7f88dc894b8c851f866032301c
- https://git.kernel.org/stable/c/b4cc04fa8f1fc3816c8494d77abab3f72b9d2292
- https://git.kernel.org/stable/c/f05a0d8de2ea49af36821a20b0b501e20ced937e
Modified: 2025-10-01
CVE-2022-49119
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req() In pm8001_chip_fw_flash_update_build(), if pm8001_chip_fw_flash_update_build() fails, the struct fw_control_ex allocated must be freed.
- https://git.kernel.org/stable/c/a25ed5f21f94f9ae4bcc8dd747e978668890c921
- https://git.kernel.org/stable/c/d83574666bac4b1462e90df393fbed6c5f57d1a3
- https://git.kernel.org/stable/c/e5ecdb01952f230921aa8163d8d7f4c97c925ed8
- https://git.kernel.org/stable/c/f792a3629f4c4aa4c3703d66b43ce1edcc3ec09a
- https://git.kernel.org/stable/c/fe5b8ea5583b5c3f6f68e06acba50387edf3b5d5
Modified: 2025-09-23
CVE-2022-49120
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix task leak in pm8001_send_abort_all() In pm8001_send_abort_all(), make sure to free the allocated sas task if pm8001_tag_alloc() or pm8001_mpi_build_cmd() fail.
- https://git.kernel.org/stable/c/146cae06d2682d7563732544be334e8e6d3862b8
- https://git.kernel.org/stable/c/2051044d7901f1a9d7be95d0d32e53b88e9548f7
- https://git.kernel.org/stable/c/2290dcad6f65864dec518fb2d5fb45f67d684150
- https://git.kernel.org/stable/c/34c79d16ee69cb53288c202bb1ab0ba0130d9674
- https://git.kernel.org/stable/c/f90a74892f3acf0cdec5844e90fc8686ca13e7d7
Modified: 2025-09-23
CVE-2022-49121
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix tag leaks on error In pm8001_chip_set_dev_state_req(), pm8001_chip_fw_flash_update_req(), pm80xx_chip_phy_ctl_req() and pm8001_chip_reg_dev_req() add missing calls to pm8001_tag_free() to free the allocated tag when pm8001_mpi_build_cmd() fails. Similarly, in pm8001_exec_internal_task_abort(), if the chip ->task_abort method fails, the tag allocated for the abort request task must be freed. Add the missing call to pm8001_tag_free().
- https://git.kernel.org/stable/c/43c617eefab7077d69f5989ad3e2a273da1d728b
- https://git.kernel.org/stable/c/4c8f04b1905cd4b776d0b720463c091545478ef7
- https://git.kernel.org/stable/c/9cc72bcc1c096ed42c91646f130d4b4191580a4c
- https://git.kernel.org/stable/c/a0bb65eadbf942024226241d9d99fed17168940b
- https://git.kernel.org/stable/c/bdc74815f1c39905054b7d47399e0260b201b14d
Modified: 2025-10-14
CVE-2022-49122
In the Linux kernel, the following vulnerability has been resolved: dm ioctl: prevent potential spectre v1 gadget It appears like cmd could be a Spectre v1 gadget as it's supplied by a user and used as an array index. Prevent the contents of kernel memory from being leaked to userspace via speculative execution by using array_index_nospec.
- https://git.kernel.org/stable/c/02cc46f397eb3691c56affbd5073e54f7a82ac32
- https://git.kernel.org/stable/c/0320bac5801b31407200227173205d017488f140
- https://git.kernel.org/stable/c/44e6cb3ab177faae840bb2c1ebda9a2539876184
- https://git.kernel.org/stable/c/58880025e3362024f6d8ea01cb0c7a5df6c84ba6
- https://git.kernel.org/stable/c/71c8df33fd777c7628f6fbc09b14e84806c55914
- https://git.kernel.org/stable/c/76c94651005f58885facf9c973007f5ea01ab01f
- https://git.kernel.org/stable/c/7ae2c5b89da3cfaf856df880af27d3bb32a74b3d
- https://git.kernel.org/stable/c/cd9c88da171a62c4b0f1c70e50c75845969fbc18
- https://git.kernel.org/stable/c/dd86064417de828ff2102ddc6049c829bf7585b4
Modified: 2025-10-01
CVE-2022-49130
In the Linux kernel, the following vulnerability has been resolved:
ath11k: mhi: use mhi_sync_power_up()
If amss.bin was missing ath11k would crash during 'rmmod ath11k_pci'. The
reason for that was that we were using mhi_async_power_up() which does not
check any errors. But mhi_sync_power_up() on the other hand does check for
errors so let's use that to fix the crash.
I was not able to find a reason why an async version was used.
ath11k_mhi_start() (which enables state ATH11K_MHI_POWER_ON) is called from
ath11k_hif_power_up(), which can sleep. So sync version should be safe to use
here.
[ 145.569731] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI
[ 145.569789] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
[ 145.569843] CPU: 2 PID: 1628 Comm: rmmod Kdump: loaded Tainted: G W 5.16.0-wt-ath+ #567
[ 145.569898] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021
[ 145.569956] RIP: 0010:ath11k_hal_srng_access_begin+0xb5/0x2b0 [ath11k]
[ 145.570028] Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 ec 01 00 00 48 8b ab a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <0f> b6 14 02 48 89 e8 83 e0 07 83 c0 03 45 85 ed 75 48 38 d0 7c 08
[ 145.570089] RSP: 0018:ffffc900025d7ac0 EFLAGS: 00010246
[ 145.570144] RAX: dffffc0000000000 RBX: ffff88814fca2dd8 RCX: 1ffffffff50cb455
[ 145.570196] RDX: 0000000000000000 RSI: ffff88814fca2dd8 RDI: ffff88814fca2e80
[ 145.570252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffa8659497
[ 145.570329] R10: fffffbfff50cb292 R11: 0000000000000001 R12: ffff88814fca0000
[ 145.570410] R13: 0000000000000000 R14: ffff88814fca2798 R15: ffff88814fca2dd8
[ 145.570465] FS: 00007fa399988540(0000) GS:ffff888233e00000(0000) knlGS:0000000000000000
[ 145.570519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 145.570571] CR2: 00007fa399b51421 CR3: 0000000137898002 CR4: 00000000003706e0
[ 145.570623] Call Trace:
[ 145.570675]
- https://git.kernel.org/stable/c/20d01a11efde2e05e47d5c66101f5c26eaca68e2
- https://git.kernel.org/stable/c/339bd0b55ecdd0f7f341e9357c4cfde799de9418
- https://git.kernel.org/stable/c/3df6d74aedfdca919cca475d15dfdbc8b05c9e5d
- https://git.kernel.org/stable/c/3fd7d50384c3808b7f7fa135aa9bb5feb1cb9849
- https://git.kernel.org/stable/c/646d533af2911be1184eaee8c900b7eb8ecc4396
Modified: 2025-10-01
CVE-2022-49131
In the Linux kernel, the following vulnerability has been resolved: ath11k: fix kernel panic during unload/load ath11k modules Call netif_napi_del() from ath11k_ahb_free_ext_irq() to fix the following kernel panic when unload/load ath11k modules for few iterations. [ 971.201365] Unable to handle kernel paging request at virtual address 6d97a208 [ 971.204227] pgd = 594c2919 [ 971.211478] [6d97a208] *pgd=00000000 [ 971.214120] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 971.412024] CPU: 2 PID: 4435 Comm: insmod Not tainted 5.4.89 #0 [ 971.434256] Hardware name: Generic DT based system [ 971.440165] PC is at napi_by_id+0x10/0x40 [ 971.445019] LR is at netif_napi_add+0x160/0x1dc [ 971.743127] (napi_by_id) from [<807d89a0>] (netif_napi_add+0x160/0x1dc) [ 971.751295] (netif_napi_add) from [<7f1209ac>] (ath11k_ahb_config_irq+0xf8/0x414 [ath11k_ahb]) [ 971.759164] (ath11k_ahb_config_irq [ath11k_ahb]) from [<7f12135c>] (ath11k_ahb_probe+0x40c/0x51c [ath11k_ahb]) [ 971.768567] (ath11k_ahb_probe [ath11k_ahb]) from [<80666864>] (platform_drv_probe+0x48/0x94) [ 971.779670] (platform_drv_probe) from [<80664718>] (really_probe+0x1c8/0x450) [ 971.789389] (really_probe) from [<80664cc4>] (driver_probe_device+0x15c/0x1b8) [ 971.797547] (driver_probe_device) from [<80664f60>] (device_driver_attach+0x44/0x60) [ 971.805795] (device_driver_attach) from [<806650a0>] (__driver_attach+0x124/0x140) [ 971.814822] (__driver_attach) from [<80662adc>] (bus_for_each_dev+0x58/0xa4) [ 971.823328] (bus_for_each_dev) from [<80663a2c>] (bus_add_driver+0xf0/0x1e8) [ 971.831662] (bus_add_driver) from [<806658a4>] (driver_register+0xa8/0xf0) [ 971.839822] (driver_register) from [<8030269c>] (do_one_initcall+0x78/0x1ac) [ 971.847638] (do_one_initcall) from [<80392524>] (do_init_module+0x54/0x200) [ 971.855968] (do_init_module) from [<803945b0>] (load_module+0x1e30/0x1ffc) [ 971.864126] (load_module) from [<803948b0>] (sys_init_module+0x134/0x17c) [ 971.871852] (sys_init_module) from [<80301000>] (ret_fast_syscall+0x0/0x50) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00760-QCAHKSWPL_SILICONZ-1
- https://git.kernel.org/stable/c/22b59cb965f79ee1accf83172441c9ca0ecb632a
- https://git.kernel.org/stable/c/38e488db194dc16d2eb23c77c6a8c04ff583c40d
- https://git.kernel.org/stable/c/699e8c87e5c406af0f0606f40eeebd248c51b702
- https://git.kernel.org/stable/c/c4b7653af62a9a5efe2856183d1f987c5429758b
- https://git.kernel.org/stable/c/c6a815f5abdf324108799829dd19ea62fef4bf95
Modified: 2025-10-01
CVE-2022-49137
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code.
- https://git.kernel.org/stable/c/3edd8646cb7c11b57c90e026bda6f21076223f5b
- https://git.kernel.org/stable/c/4009f104b02b223d1a11d74b36b1cc083bc37028
- https://git.kernel.org/stable/c/72d77ddb2224ebc00648f4f78f8a9a259dccbdf7
- https://git.kernel.org/stable/c/927beb05aaa429c883cc0ec6adc48964b187e291
- https://git.kernel.org/stable/c/b6d1f7d97c81ebaf2cda9c4c943ee2e484fffdcf
- https://git.kernel.org/stable/c/bc2d5c0775c839e2b072884f4ee6a93ba410f107
- https://git.kernel.org/stable/c/dfced44f122c500004a48ecc8db516bb6a295a1b
