ALT-BU-2022-5656-12
Branch sisyphus update bulletin.
Package kernel-image-mp updated to version 5.18.16-alt1 for branch sisyphus in task 304714.
Closed vulnerabilities
Modified: 2024-09-30
BDU:2022-04686
Уязвимость модуля nfnetlink_queue ядра операционных систем Linux, связанная с некорректной обработкой вердиктов с однобайтным атрибутом nfta_payload, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-13
BDU:2022-04725
Уязвимость функции clear_bss ядра операционных систем Linux, связанная с ошибками при очистке начального символа блока (.bss), позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-05664
Уязвимость функции xfrm_expand_policies (net/xfrm/xfrm_policy.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-06-04
BDU:2023-08897
Уязвимость функции free_pipe_info файла fs/pipe.c ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2024-07839
Уязвимость компонента vt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04335
Уязвимость функции find_css_set() модуля kernel/cgroup/cgroup.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-04336
Уязвимость функции nft_unregister_flowtable_type() модуля include/net/netfilter/nf_tables.h ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-04422
Уязвимость функции efx_ef10_pci_sriov_disable() модуля drivers/net/ethernet/sfc/ef10_sriov.c - драйвера поддержки сетевых адаптеров Ethernet Solarflare ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-29
BDU:2025-12488
Уязвимость функций ndo_uninit(), dev->priv_destructor() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01504
Уязвимость функции pot_hole() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02204
Уязвимость функции common() модуля arch/x86/kernel/asm-offsets.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02206
Уязвимость функции rt700_jack_detect_handler() модуля sound/soc/codecs/rt700.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02226
Уязвимость функции mpol_rebind_preferred() модуля mm/mempolicy.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02227
Уязвимость функции spectre_v2_select_mitigation() модуля arch/x86/kernel/cpu/bugs.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02228
Уязвимость функции mc_probe() модуля sound/soc/intel/boards/sof_sdw.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02229
Уязвимость функции tipc_sk_create() модуля net/tipc/socket.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02252
Уязвимость функции xive_irq_bitmap_add() модуля arch/powerpc/sysdev/xive/spapr.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02581
Уязвимость функции qat_dh_compute_value() модуля drivers/crypto/qat/qat_common/qat_asym_algs.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02624
Уязвимость функции pmac_cpufreq_init_MacRISC3() модуля drivers/cpufreq/pmac32-cpufreq.c - драйвера поддержки масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02646
Уязвимость функции kvm_ioctl_create_device() модуля virt/kvm/kvm_main.c подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02651
Уязвимость функции qat_rsa_enc() модуля drivers/crypto/qat/qat_common/qat_asym_algs.c - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03249
Уязвимость функции reuseport_stop_listen_sock() модуля net/core/sock_reuseport.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03290
Уязвимость функции proc_dou8vec_minmax() модуля kernel/sysctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03698
Уязвимость функции be_cmd_read_port_transceiver_data() модуля drivers/net/ethernet/emulex/benet/be_cmds.c драйвера поддержки сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03699
Уязвимость функции ixgbe_sw_init() модуля drivers/net/ethernet/intel/ixgbe/ixgbe_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03700
Уязвимость функции igc_rd32() модуля drivers/net/ethernet/intel/igc/igc_main.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03701
Уязвимость функции irdma_cm_teardown_connections() модуля drivers/infiniband/hw/irdma/cm.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03702
Уязвимость функции atl_resume_common() модуля drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c драйвера поддержки сетевых адаптеров Ethernet с чипсетом aQuantia Atlantic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03877
Уязвимость функции serial8250_register_ports() модуля drivers/tty/serial/8250/8250_core.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03902
Уязвимость функции efx_ef10_try_update_nic_stats_vf() модуля drivers/net/ethernet/sfc/ef10.c драйвера поддержки сетевых адаптеров Ethernet Solarflare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03907
Уязвимость функции panfrost_ioctl_madvise() модуля drivers/gpu/drm/panfrost/panfrost_drv.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03915
Уязвимость функции power_supply_temp2resist_simple() модуля drivers/power/supply/power_supply_core.c драйвера поддержки управления питанием ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04002
Уязвимость функции tegra_eqos_probe() модуля drivers/net/ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c драйвера поддержки сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04003
Уязвимость функции ingenic_mac_probe() модуля drivers/net/ethernet/stmicro/stmmac/dwmac-ingenic.c драйвера поддержки сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04046
Уязвимость функции dwmac4_map_mtl_dma() модуля drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c драйвера поддержки сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-11-21
CVE-2022-1882
A use-after-free flaw was found in the Linux kernel’s pipes functionality in how a user performs manipulations with the pipe post_one_notification() after free_pipe_info() that is already called. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://bugzilla.redhat.com/show_bug.cgi?id=2089701
- https://lore.kernel.org/lkml/20220507115605.96775-1-tcs.kernel%40gmail.com/T/
- https://security.netapp.com/advisory/ntap-20220715-0002/
- https://bugzilla.redhat.com/show_bug.cgi?id=2089701
- https://lore.kernel.org/lkml/20220507115605.96775-1-tcs.kernel%40gmail.com/T/
- https://security.netapp.com/advisory/ntap-20220715-0002/
Modified: 2024-11-21
CVE-2022-36123
The Linux kernel before 5.18.13 lacks a certain clear operation for the block starting symbol (.bss). This allows Xen PV guest OS users to cause a denial of service or gain privileges.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.13
- https://github.com/sickcodes/security/blob/master/advisories/SICK-2022-128.md
- https://github.com/torvalds/linux/commit/74a0032b8524ee2bd4443128c0bf9775928680b0
- https://github.com/torvalds/linux/commit/96e8fc5818686d4a1591bb6907e7fdb64ef29884
- https://security.netapp.com/advisory/ntap-20220901-0003/
- https://sick.codes/sick-2022-128
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.13
- https://github.com/sickcodes/security/blob/master/advisories/SICK-2022-128.md
- https://github.com/torvalds/linux/commit/74a0032b8524ee2bd4443128c0bf9775928680b0
- https://github.com/torvalds/linux/commit/96e8fc5818686d4a1591bb6907e7fdb64ef29884
- https://security.netapp.com/advisory/ntap-20220901-0003/
- https://sick.codes/sick-2022-128
Modified: 2025-05-05
CVE-2022-36879
An issue was discovered in the Linux kernel through 5.18.14. xfrm_expand_policies in net/xfrm/xfrm_policy.c can cause a refcount to be dropped twice.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f85daf0e725358be78dfd208dea5fd665d8cb901
- https://github.com/torvalds/linux/commit/f85daf0e725358be78dfd208dea5fd665d8cb901
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f85daf0e725358be78dfd208dea5fd665d8cb901
- https://github.com/torvalds/linux/commit/f85daf0e725358be78dfd208dea5fd665d8cb901
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
Modified: 2025-05-05
CVE-2022-36946
nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte nfta_payload attribute, an skb_pull can encounter a negative skb->len.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://marc.info/?l=netfilter-devel&m=165883202007292&w=2
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://marc.info/?l=netfilter-devel&m=165883202007292&w=2
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
Modified: 2025-04-29
CVE-2022-48627
In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew.
- https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265
- https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc
- https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244
- https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c
- https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926
- https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29
- https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265
- https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc
- https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244
- https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c
- https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926
- https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-10-01
CVE-2022-49563
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for RSA Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.
Modified: 2025-10-01
CVE-2022-49564
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for DH Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.
Modified: 2025-10-22
CVE-2022-49565
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/lbr: Fix unchecked MSR access error on HSW
The fuzzer triggers the below trace.
[ 7763.384369] unchecked MSR access error: WRMSR to 0x689
(tried to write 0x1fffffff8101349e) at rIP: 0xffffffff810704a4
(native_write_msr+0x4/0x20)
[ 7763.397420] Call Trace:
[ 7763.399881]
Modified: 2025-10-01
CVE-2022-49566
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix memory leak in RSA When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is used, some components of the private key persist even after the TFM is released. Replace the explicit calls to free the buffers in qat_rsa_exit_tfm() with a call to qat_rsa_clear_ctx() which frees all buffers referenced in the TFM context.
Modified: 2025-12-23
CVE-2022-49567
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix uninit-value in mpol_rebind_policy() mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask when pol->mode is MPOL_LOCAL. Check pol->mode before access pol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c). BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline] BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae KMSAN: uninit-value in mpol_rebind_task (2) https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dc This patch seems to fix below bug too. KMSAN: uninit-value in mpol_rebind_mm (2) https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926b The uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy(). When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c `mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags` is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags; will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind() pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized, which will be accessed in mpol_rebind_policy().
Modified: 2025-10-01
CVE-2022-49568
In the Linux kernel, the following vulnerability has been resolved: KVM: Don't null dereference ops->destroy A KVM device cleanup happens in either of two callbacks: 1) destroy() which is called when the VM is being destroyed; 2) release() which is called when a device fd is closed. Most KVM devices use 1) but Book3s's interrupt controller KVM devices (XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during the machine execution. The error handling in kvm_ioctl_create_device() assumes destroy() is always defined which leads to NULL dereference as discovered by Syzkaller. This adds a checks for destroy!=NULL and adds a missing release(). This is not changing kvm_destroy_devices() as devices with defined release() should have been removed from the KVM devices list by then.
- https://git.kernel.org/stable/c/170465715a60cbb7876e6b961b21bd3225469da8
- https://git.kernel.org/stable/c/3616776bc51cd3262bb1be60cc01c72e0a1959cf
- https://git.kernel.org/stable/c/d4a5a79b780891c5cbdfdc6124d46fdf8d13dba1
- https://git.kernel.org/stable/c/e8bc2427018826e02add7b0ed0fc625a60390ae5
- https://git.kernel.org/stable/c/e91665fbbf3ccb268b268a7d71a6513538d813ac
Modified: 2025-10-01
CVE-2022-49569
In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA transfers In case a IRQ based transfer times out the bcm2835_spi_handle_err() function is called. Since commit 1513ceee70f2 ("spi: bcm2835: Drop dma_pending flag") the TX and RX DMA transfers are unconditionally canceled, leading to NULL pointer derefs if ctlr->dma_tx or ctlr->dma_rx are not set. Fix the NULL pointer deref by checking that ctlr->dma_tx and ctlr->dma_rx are valid pointers before accessing them.
- https://git.kernel.org/stable/c/49ffa473218012e765682343de2052eb4c1f06a7
- https://git.kernel.org/stable/c/4ceaa684459d414992acbefb4e4c31f2dfc50641
- https://git.kernel.org/stable/c/58466e05390043d2805685c70f55f3f59711bdf2
- https://git.kernel.org/stable/c/684896e675edd8b669fd3e9f547c5038222d85bc
- https://git.kernel.org/stable/c/76668d2a2f367d25ff448e6d7087406af7d7bb2b
Modified: 2025-10-01
CVE-2022-49570
In the Linux kernel, the following vulnerability has been resolved: gpio: gpio-xilinx: Fix integer overflow Current implementation is not able to configure more than 32 pins due to incorrect data type. So type casting with unsigned long to avoid it.
Modified: 2025-10-01
CVE-2022-49571
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_max_reordering. While reading sysctl_tcp_max_reordering, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/064852663308c801861bd54789d81421fa4c2928
- https://git.kernel.org/stable/c/46deb91ac8a790286ad6d24cf92e7ab0ab2582bb
- https://git.kernel.org/stable/c/50a1d3d097503a90cf84ebe120afcde37e9c33b3
- https://git.kernel.org/stable/c/5e38cee24f19d19280c68f1ac8bf6790d607f60a
- https://git.kernel.org/stable/c/a11e5b3e7a59fde1a90b0eaeaa82320495cf8cae
- https://git.kernel.org/stable/c/ce3731c61589ed73364a5b55ce34131762ef9b60
Modified: 2025-10-01
CVE-2022-49572
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_slow_start_after_idle. While reading sysctl_tcp_slow_start_after_idle, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/0e3f82a03ec8c3808e87283e12946227415706c9
- https://git.kernel.org/stable/c/369d99c2b89f54473adcf9acdf40ea562b5a6e0e
- https://git.kernel.org/stable/c/3b26e11b07a09b31247688bec61e2925d4a571b6
- https://git.kernel.org/stable/c/41aeba4506f6b70ec7500c6fe202731a4ba29fe5
- https://git.kernel.org/stable/c/4845b5713ab18a1bb6e31d1fbb4d600240b8b691
- https://git.kernel.org/stable/c/68b6f9506747d507c7bfa374d178929b4157e8c6
Modified: 2025-10-01
CVE-2022-49573
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_early_retrans. While reading sysctl_tcp_early_retrans, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/11e8b013d16e5db63f8f76acceb5b86964098aaa
- https://git.kernel.org/stable/c/488d3ad98ef7cddce7054193dbae6b4349c6807d
- https://git.kernel.org/stable/c/5037ca9e4b169cc9aed0174d658c3d81fdaf8ea5
- https://git.kernel.org/stable/c/52e65865deb6a36718a463030500f16530eaab74
- https://git.kernel.org/stable/c/83767fe800a311370330d4ec83aa76093b744a80
- https://git.kernel.org/stable/c/d5975f6376ce90c2c483ae36bf88c9cface4c13b
Modified: 2025-10-01
CVE-2022-49574
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_recovery. While reading sysctl_tcp_recovery, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/52ee7f5c4811ce6be1becd14d38ba1f8a8a0df81
- https://git.kernel.org/stable/c/92c35113c63306091df9211375eebd0abd8c2160
- https://git.kernel.org/stable/c/a31e2d0cb5cfa2aae3144cac04f25031d5d20fb4
- https://git.kernel.org/stable/c/c7a492db1f7c37c758a66915908677bd8bc5d368
- https://git.kernel.org/stable/c/d8781f7cd04091744f474a2bada74772084b9dc9
- https://git.kernel.org/stable/c/e7d2ef837e14a971a05f60ea08c47f3fed1a36e4
Modified: 2025-10-01
CVE-2022-49575
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_thin_linear_timeouts. While reading sysctl_tcp_thin_linear_timeouts, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/404c53ccdebd11f96954f4070cffac8e0b4d5cb6
- https://git.kernel.org/stable/c/492f3713b282c0e67e951cd804edd22eccc25412
- https://git.kernel.org/stable/c/7c6f2a86ca590d5187a073d987e9599985fb1c7c
- https://git.kernel.org/stable/c/a0f96c4f179cb3560078cefccef105e8f1701210
- https://git.kernel.org/stable/c/cc133e4f4bc225079198192623945bb872c08143
- https://git.kernel.org/stable/c/f4b0295be9a3c4260de4585fac4062e602a88ac7
Modified: 2025-10-01
CVE-2022-49576
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix data-races around sysctl_fib_multipath_hash_fields. While reading sysctl_fib_multipath_hash_fields, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49577
In the Linux kernel, the following vulnerability has been resolved: udp: Fix a data-race around sysctl_udp_l3mdev_accept. While reading sysctl_udp_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/3d72bb4188c708bb16758c60822fc4dda7a95174
- https://git.kernel.org/stable/c/3f2ac2d6511bb0652abf4d7388d65bb9ff1c641c
- https://git.kernel.org/stable/c/cb0d28934ca10f99c47e2c6f451405d6c954fe48
- https://git.kernel.org/stable/c/f39b03bd727a8fea62e82f10fe2e0d753b9930ff
- https://git.kernel.org/stable/c/fcaef69c79ec222e55643e666b80b221e70fa6a8
Modified: 2025-10-01
CVE-2022-49578
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_prot_sock. sysctl_ip_prot_sock is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing.
Modified: 2025-10-01
CVE-2022-49579
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix data-races around sysctl_fib_multipath_hash_policy. While reading sysctl_fib_multipath_hash_policy, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49580
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix a data-race around sysctl_fib_multipath_use_neigh. While reading sysctl_fib_multipath_use_neigh, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/14e996577ed2799a1ed6ffeb71c76d63acb28444
- https://git.kernel.org/stable/c/6727f39e99e0f545d815edebb6c94228485427ec
- https://git.kernel.org/stable/c/87507bcb4f5de16bb419e9509d874f4db6c0ad0f
- https://git.kernel.org/stable/c/b8d345db03b4deffb4f04219a51d3b1e94171b76
- https://git.kernel.org/stable/c/e045d672ba06e1d35bacb56374d350de0ac99066
Modified: 2025-10-22
CVE-2022-49581
In the Linux kernel, the following vulnerability has been resolved: be2net: Fix buffer overflow in be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case. Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only copy the bytes once.
- https://git.kernel.org/stable/c/18043da94c023f3ef09c15017bdb04e8f695ef10
- https://git.kernel.org/stable/c/665cbe91de2f7c97c51ca8fce39aae26477c1948
- https://git.kernel.org/stable/c/8ff4f9df73e5c551a72ee6034886c17e8de6596d
- https://git.kernel.org/stable/c/a5a8fc0679a8fd58d47aa2ebcfc5742631f753f9
- https://git.kernel.org/stable/c/a8569f76df7ec5b4b51155c57523a0b356db5741
- https://git.kernel.org/stable/c/aba8ff847f4f927ad7a1a1ee4a9f29989a1a728f
- https://git.kernel.org/stable/c/d7241f679a59cfe27f92cb5c6272cb429fb1f7ec
- https://git.kernel.org/stable/c/fe4473fc7940f14c4a12db873b9729134c212654
Modified: 2025-10-01
CVE-2022-49582
In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix NULL pointer dereference in dsa_port_reset_vlan_filtering The "ds" iterator variable used in dsa_port_reset_vlan_filtering() -> dsa_switch_for_each_port() overwrites the "dp" received as argument, which is later used to call dsa_port_vlan_filtering() proper. As a result, switches which do enter that code path (the ones with vlan_filtering_is_global=true) will dereference an invalid dp in dsa_port_reset_vlan_filtering() after leaving a VLAN-aware bridge. Use a dedicated "other_dp" iterator variable to avoid this from happening.
Modified: 2025-10-01
CVE-2022-49583
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix handling of dummy receive descriptors Fix memory leak caused by not handling dummy receive descriptor properly. iavf_get_rx_buffer now sets the rx_buffer return value for dummy receive descriptors. Without this patch, when the hardware writes a dummy descriptor, iavf would not free the page allocated for the previous receive buffer. This is an unlikely event but can still happen. [Jesse: massaged commit message]
- https://git.kernel.org/stable/c/2918419c06088f6709ceb543feb01752779ade4c
- https://git.kernel.org/stable/c/6edb818732fc05fda495f5b3a749bd1cee01398b
- https://git.kernel.org/stable/c/a9f49e0060301a9bfebeca76739158d0cf91cdf6
- https://git.kernel.org/stable/c/c6af94324911ef0846af1a5ce5e049ca736db34b
- https://git.kernel.org/stable/c/d88d59faf4e6f9cc4767664206afdb999b10ec77
Modified: 2025-10-22
CVE-2022-49584
In the Linux kernel, the following vulnerability has been resolved:
ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero
It is possible to disable VFs while the PF driver is processing requests
from the VF driver. This can result in a panic.
BUG: unable to handle kernel paging request at 000000000000106c
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 8 PID: 0 Comm: swapper/8 Kdump: loaded Tainted: G I --------- -
Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020
RIP: 0010:ixgbe_msg_task+0x4c8/0x1690 [ixgbe]
Code: 00 00 48 8d 04 40 48 c1 e0 05 89 7c 24 24 89 fd 48 89 44 24 10 83 ff
01 0f 84 b8 04 00 00 4c 8b 64 24 10 4d 03 a5 48 22 00 00 <41> 80 7c 24 4c
00 0f 84 8a 03 00 00 0f b7 c7 83 f8 08 0f 84 8f 0a
RSP: 0018:ffffb337869f8df8 EFLAGS: 00010002
RAX: 0000000000001020 RBX: 0000000000000000 RCX: 000000000000002b
RDX: 0000000000000002 RSI: 0000000000000008 RDI: 0000000000000006
RBP: 0000000000000006 R08: 0000000000000002 R09: 0000000000029780
R10: 00006957d8f42832 R11: 0000000000000000 R12: 0000000000001020
R13: ffff8a00e8978ac0 R14: 000000000000002b R15: ffff8a00e8979c80
FS: 0000000000000000(0000) GS:ffff8a07dfd00000(0000) knlGS:00000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000106c CR3: 0000000063e10004 CR4: 00000000007726e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/031af9e617a6f51075d97e56fc9e712c7dde2508
- https://git.kernel.org/stable/c/16f929a5e76fd047fd8697e1e568bdd7d771955c
- https://git.kernel.org/stable/c/1e53834ce541d4fe271cdcca7703e50be0a44f8a
- https://git.kernel.org/stable/c/9d925d2dc82cec2bcbd8625457645d8a548ab22e
- https://git.kernel.org/stable/c/b82de63f8f817b5735480293dda8e92ba8170c52
Modified: 2025-10-01
CVE-2022-49585
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_fastopen_blackhole_timeout. While reading sysctl_tcp_fastopen_blackhole_timeout, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49586
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_fastopen. While reading sysctl_tcp_fastopen, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/03da610696a32578fc4f986479341ce9d430df08
- https://git.kernel.org/stable/c/22938534c611136f35e2ca545bb668073ca5ef49
- https://git.kernel.org/stable/c/25d53d858a6c0b89a6e69e376c2a57c4f4c2c8cc
- https://git.kernel.org/stable/c/448ab998947996a0a451f8229f19087964cf2670
- https://git.kernel.org/stable/c/539d9ab79eba3974b479cad61a8688c41fe62e12
- https://git.kernel.org/stable/c/5a54213318c43f4009ae158347aa6016e3b9b55a
Modified: 2025-10-01
CVE-2022-49587
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_notsent_lowat. While reading sysctl_tcp_notsent_lowat, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/0f75343584ee474303e17efe0610bdd170af1d13
- https://git.kernel.org/stable/c/55be873695ed8912eb77ff46d1d1cadf028bd0f3
- https://git.kernel.org/stable/c/62e56cfeb2ae4b53ae9ca24c80f54093250ce64a
- https://git.kernel.org/stable/c/80d4d0c461674eea87f0977e12a2ecd334b9b79c
- https://git.kernel.org/stable/c/91e21df688f8a75255ca9c459da39ac96300113a
- https://git.kernel.org/stable/c/c1b85c5a34294f7444c13bf828e0e84b0a0eed85
- https://git.kernel.org/stable/c/e9362a993886613ef0284c2a4911c6017c97d803
- https://git.kernel.org/stable/c/fd6f1284e380c377932186042ff0b5c987fb2b92
Modified: 2025-10-01
CVE-2022-49588
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_migrate_req. While reading sysctl_tcp_migrate_req, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49589
In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_qrv. While reading sysctl_igmp_qrv, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);
- https://git.kernel.org/stable/c/8ebcc62c738f68688ee7c6fec2efe5bc6d3d7e60
- https://git.kernel.org/stable/c/9eeb3a7702998bdccbfcc37997b5dd9215b9a7f7
- https://git.kernel.org/stable/c/b399ffafffba39f47b731b26a5da1dc0ffc4b3ad
- https://git.kernel.org/stable/c/c2954671010cd1127d1ffa328c6e6f8e99930982
- https://git.kernel.org/stable/c/c721324afc589f8ea54bae04756b150aeaae5fa4
- https://git.kernel.org/stable/c/e20dd1b0e0ea15bee1e528536a0840dba972ca0e
Modified: 2025-10-01
CVE-2022-49590
In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_llm_reports. While reading sysctl_igmp_llm_reports, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))
- https://git.kernel.org/stable/c/1656ecaddf90e2a070ec2d2404cdae3edf80faca
- https://git.kernel.org/stable/c/260446eb8e5541402b271343a4516f2b33dec1e4
- https://git.kernel.org/stable/c/46307adceb67bdf2ec38408dd9cebc378a6b5c46
- https://git.kernel.org/stable/c/473aad9ad57ff760005377e6f45a2ad4210e08ce
- https://git.kernel.org/stable/c/a84b4afaca2573ed3aed1f8854aefe3ca5a82e72
- https://git.kernel.org/stable/c/d77969e7d4ccc26bf1f414a39ef35050a83ba6d5
- https://git.kernel.org/stable/c/ed876e99ccf417b8bd7fd8408ba5e8b008e46cc8
- https://git.kernel.org/stable/c/f6da2267e71106474fbc0943dc24928b9cb79119
Modified: 2025-10-01
CVE-2022-49591
In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: ksz_common: Fix refcount leak bug In ksz_switch_register(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount.
Modified: 2025-10-22
CVE-2022-49592
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: fix dma queue left shift overflow issue
When queue number is > 4, left shift overflows due to 32 bits
integer variable. Mask calculation is wrong for MTL_RXQ_DMA_MAP1.
If CONFIG_UBSAN is enabled, kernel dumps below warning:
[ 10.363842] ==================================================================
[ 10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/
linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:224:12
[ 10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int'
[ 10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg
[ 10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021
[ 10.363958] Call Trace:
[ 10.363960]
- https://git.kernel.org/stable/c/508d86ead36cbd8dfb60773a33276790d668c473
- https://git.kernel.org/stable/c/573768dede0e2b7de38ecbc11cb3ee47643902dc
- https://git.kernel.org/stable/c/613b065ca32e90209024ec4a6bb5ca887ee70980
- https://git.kernel.org/stable/c/7c687a893f5cae5ca40d189635602e93af9bab73
- https://git.kernel.org/stable/c/a3ac79f38d354b10925824899cdbd2caadce55ba
- https://git.kernel.org/stable/c/ad2febdfbd01e1d092a08bfdba92ede79ea05ff3
- https://git.kernel.org/stable/c/e846bde09677fa3b203057846620b7ed96540f5f
Modified: 2025-10-01
CVE-2022-49593
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_probe_interval. While reading sysctl_tcp_probe_interval, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/2a85388f1d94a9f8b5a529118a2c5eaa0520d85c
- https://git.kernel.org/stable/c/73a11588751a2c13f25d9da8117efc9a79b1843f
- https://git.kernel.org/stable/c/80dabd089086e6553b7acfcff2ec223bdada87a1
- https://git.kernel.org/stable/c/b14cc8afbbcbc6dce4797913c0b85266b897f541
- https://git.kernel.org/stable/c/b3798d3519eda9c409bb0815b0102f27ec42468d
- https://git.kernel.org/stable/c/c61aede097d350d890fa1edc9521b0072e14a0b8
- https://git.kernel.org/stable/c/e6b6f027e2854a51f345a5e3e808d7a88001d4f8
Modified: 2025-10-01
CVE-2022-49594
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_mtu_probe_floor. While reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/033963b220633ed1602d458e7e4ac06afa9fefb2
- https://git.kernel.org/stable/c/8e92d4423615a5257d0d871fc067aa561f597deb
- https://git.kernel.org/stable/c/cc36c37f5fe066c4708e623ead96dc8f57224bf5
- https://git.kernel.org/stable/c/d5bece4df6090395f891110ef52a6f82d16685db
- https://git.kernel.org/stable/c/e2ecbf3f0aa88277d43908c53b99399d55729ff9
Modified: 2025-10-01
CVE-2022-49595
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_probe_threshold. While reading sysctl_tcp_probe_threshold, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/44768749980d53bc01980d9c060f736808d11af0
- https://git.kernel.org/stable/c/92c0aa4175474483d6cf373314343d4e624e882a
- https://git.kernel.org/stable/c/96900fa61777402eb5056269d8000aace33a8b6c
- https://git.kernel.org/stable/c/9b5dc7ad6da1373d3c60d4b869d688f996e5d219
- https://git.kernel.org/stable/c/b04817c94fbd285a967d9b830b274fe9998c9c0b
- https://git.kernel.org/stable/c/d452ce36f2d4c402fa3f5275c9677f80166e7fc6
- https://git.kernel.org/stable/c/f524c3e7f6cdad66b3b6a912cef47b656f8b0de3
- https://git.kernel.org/stable/c/fa5fb2cf9393db898772db8cb897ed5fd265eb78
Modified: 2025-10-01
CVE-2022-49596
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_min_snd_mss. While reading sysctl_tcp_min_snd_mss, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/0d8a39feb58910a7f7746b1770ee5578cc551fe6
- https://git.kernel.org/stable/c/0fc9357282df055e30990b29f4b7afa53ab42cdb
- https://git.kernel.org/stable/c/78eb166cdefcc3221c8c7c1e2d514e91a2eb5014
- https://git.kernel.org/stable/c/97992e8feff33b3ae154a113ec398546bbacda80
- https://git.kernel.org/stable/c/fdb96b69f5909ffcdd6f1e0902219fc6d7689ff7
Modified: 2025-10-01
CVE-2022-49597
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_base_mss. While reading sysctl_tcp_base_mss, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/30b73edc1d2459ba2c71cb58fbf84a1a6e640fbf
- https://git.kernel.org/stable/c/4d7dea651b7fe0322be95054f64e3711afccc543
- https://git.kernel.org/stable/c/514d2254c7b8aa2d257f5ffc79f0d96be2d6bfda
- https://git.kernel.org/stable/c/88d78bc097cd8ebc6541e93316c9d9bf651b13e8
- https://git.kernel.org/stable/c/9ca18116bc16ec31b9a3ce28ea1350badfa36128
Modified: 2025-10-01
CVE-2022-49598
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_mtu_probing. While reading sysctl_tcp_mtu_probing, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/77a04845f0d28a3561494a5f3121488470a968a4
- https://git.kernel.org/stable/c/7e8fc428a7f680f1c4994a40e52d7f95a9a93038
- https://git.kernel.org/stable/c/aabe9438fdfe004e021d5a206227ec105dbe2416
- https://git.kernel.org/stable/c/b0920ca09d9ce19980c8391b9002455baa9c1417
- https://git.kernel.org/stable/c/f47d00e077e7d61baf69e46dde3210c886360207
- https://git.kernel.org/stable/c/f966773e13cdd3f12baa90071b7b660f6c633ccb
Modified: 2025-10-01
CVE-2022-49599
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_l3mdev_accept. While reading sysctl_tcp_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49600
In the Linux kernel, the following vulnerability has been resolved: ip: Fix a data-race around sysctl_ip_autobind_reuse. While reading sysctl_ip_autobind_reuse, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
Modified: 2025-10-01
CVE-2022-49601
In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Fix a data-race around sysctl_tcp_fwmark_accept. While reading sysctl_tcp_fwmark_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/13207f9485b5de68decf296ceb0046f5eabb2485
- https://git.kernel.org/stable/c/1a0008f9df59451d0a17806c1ee1a19857032fa8
- https://git.kernel.org/stable/c/45fc82706a97242539d6b841ddd7a077ec20757b
- https://git.kernel.org/stable/c/526d8cf8824f613c72dba2155542295e70135f62
- https://git.kernel.org/stable/c/a7386602a2fe2f6192477e8ede291a815da09d81
- https://git.kernel.org/stable/c/abf70de2ec026ae8d7da4e79bec61888a880e00b
- https://git.kernel.org/stable/c/bf3134feffe61b7a0e21f60a04743f8da0958b53
- https://git.kernel.org/stable/c/d4f65615db7fca3df9f7e79eadf937e6ddb03c54
Modified: 2025-10-01
CVE-2022-49602
In the Linux kernel, the following vulnerability has been resolved: ip: Fix a data-race around sysctl_fwmark_reflect. While reading sysctl_fwmark_reflect, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/0ee76fe01ff3c0b4efaa500aecc90d7c8d3a8860
- https://git.kernel.org/stable/c/25a635a67c830766110410fea88ec4e6ee29684b
- https://git.kernel.org/stable/c/5e7a1be3e68deef250ad43cc91f7bb8d7d758b48
- https://git.kernel.org/stable/c/85d0b4dbd74b95cc492b1f4e34497d3f894f5d9a
- https://git.kernel.org/stable/c/9096edcf4854289f92252e086cf6e498c7f8c21d
- https://git.kernel.org/stable/c/a475ecc9ad919aa3ebdd4e4a6ee612b793bf74b3
- https://git.kernel.org/stable/c/dccf8a67f30e18980d13f07006e5a536bbd1e136
- https://git.kernel.org/stable/c/fc92e3b4bebfdd986ef1d2c5019f236837b0b982
Modified: 2025-10-01
CVE-2022-49603
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_fwd_update_priority. While reading sysctl_ip_fwd_update_priority, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49604
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_fwd_use_pmtu. While reading sysctl_ip_fwd_use_pmtu, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
- https://git.kernel.org/stable/c/60c158dc7b1f0558f6cadd5b50d0386da0000d50
- https://git.kernel.org/stable/c/7828309df0f89419a9349761a37c7d1b0da45697
- https://git.kernel.org/stable/c/93fbc06da1d819f3981a7bd7928c3641ea67b364
- https://git.kernel.org/stable/c/b96ed5ccb09ae71103023ed13acefb194f609794
- https://git.kernel.org/stable/c/e364b5f6ffbfc457a997ad09a7baa16c19581edc
- https://git.kernel.org/stable/c/eb15262128b793e4b1d1c4514d3e6d19c3959764
Modified: 2025-10-23
CVE-2022-49605
In the Linux kernel, the following vulnerability has been resolved: igc: Reinstate IGC_REMOVED logic and implement it properly The initially merged version of the igc driver code (via commit 146740f9abc4, "igc: Add support for PF") contained the following IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors: u32 igc_rd32(struct igc_hw *hw, u32 reg) { u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr); u32 value = 0; if (IGC_REMOVED(hw_addr)) return ~value; value = readl(&hw_addr[reg]); /* reads should not return all F's */ if (!(~value) && (!reg || !(~readl(hw_addr)))) hw->hw_addr = NULL; return value; } And: #define wr32(reg, val) \ do { \ u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \ if (!IGC_REMOVED(hw_addr)) \ writel((val), &hw_addr[(reg)]); \ } while (0) E.g. igb has similar checks in its MMIO accessors, and has a similar macro E1000_REMOVED, which is implemented as follows: #define E1000_REMOVED(h) unlikely(!(h)) These checks serve to detect and take note of an 0xffffffff MMIO read return from the device, which can be caused by a PCIe link flap or some other kind of PCI bus error, and to avoid performing MMIO reads and writes from that point onwards. However, the IGC_REMOVED macro was not originally implemented: #ifndef IGC_REMOVED #define IGC_REMOVED(a) (0) #endif /* IGC_REMOVED */ This led to the IGC_REMOVED logic to be removed entirely in a subsequent commit (commit 3c215fb18e70, "igc: remove IGC_REMOVED function"), with the rationale that such checks matter only for virtualization and that igc does not support virtualization -- but a PCIe device can become detached even without virtualization being in use, and without proper checks, a PCIe bus error affecting an igc adapter will lead to various NULL pointer dereferences, as the first access after the error will set hw->hw_addr to NULL, and subsequent accesses will blindly dereference this now-NULL pointer. This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), and implements IGC_REMOVED the way it is done for igb, by checking for the unlikely() case of hw_addr being NULL. This change prevents the oopses seen when a PCIe link flap occurs on an igc adapter.
- https://git.kernel.org/stable/c/16cb6717f4f42487ef10583eb8bc98e7d1e33d65
- https://git.kernel.org/stable/c/70965b6e5c03aa70cc754af1226b9f9cde0c4bf3
- https://git.kernel.org/stable/c/77836dbe35382aaf8108489060c5c89530c77494
- https://git.kernel.org/stable/c/7c1ddcee5311f3315096217881d2dbe47cc683f9
- https://git.kernel.org/stable/c/e75b73081f1ec169518773626c2ff3950476660b
Modified: 2025-10-23
CVE-2022-49606
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix sleep from invalid context BUG Taking the qos_mutex to process RoCEv2 QP's on netdev events causes a kernel splat. Fix this by removing the handling for RoCEv2 in irdma_cm_teardown_connections that uses the mutex. This handling is only needed for iWARP to avoid having connections established while the link is down or having connections remain functional after the IP address is removed. BUG: sleeping function called from invalid context at kernel/locking/mutex. Call Trace: kernel: dump_stack+0x66/0x90 kernel: ___might_sleep.cold.92+0x8d/0x9a kernel: mutex_lock+0x1c/0x40 kernel: irdma_cm_teardown_connections+0x28e/0x4d0 [irdma] kernel: ? check_preempt_curr+0x7a/0x90 kernel: ? select_idle_sibling+0x22/0x3c0 kernel: ? select_task_rq_fair+0x94c/0xc90 kernel: ? irdma_exec_cqp_cmd+0xc27/0x17c0 [irdma] kernel: ? __wake_up_common+0x7a/0x190 kernel: irdma_if_notify+0x3cc/0x450 [irdma] kernel: ? sched_clock_cpu+0xc/0xb0 kernel: irdma_inet6addr_event+0xc6/0x150 [irdma]
Modified: 2025-10-01
CVE-2022-49607
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix data race between perf_event_set_output() and perf_mmap_close() Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list) After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } } The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. As such there is no serialization to avoid this race. Change perf_event_set_output() to take both e1->mmap_mutex and e2->mmap_mutex to alleviate that problem. Additionally, have the loop in perf_mmap() detach the rb directly, this avoids having to wait for the concurrent perf_mmap_close() to get around to doing it to make progress.
- https://git.kernel.org/stable/c/17f5417194136517ee9bbd6511249e5310e5617c
- https://git.kernel.org/stable/c/3bbd868099287ff9027db59029b502fcfa2202a0
- https://git.kernel.org/stable/c/43128b3eee337824158f34da6648163d2f2fb937
- https://git.kernel.org/stable/c/68e3c69803dada336893640110cb87221bb01dcf
- https://git.kernel.org/stable/c/98c3c8fd0d4c560e0f8335b79c407bbf7fc9462c
- https://git.kernel.org/stable/c/a9391ff7a7c5f113d6f2bf6621d49110950de49c
- https://git.kernel.org/stable/c/da3c256e2d0ebc87c7db0c605c9692b6f1722074
- https://git.kernel.org/stable/c/f836f9ac95df15f1e0af4beb0ec20021e8c91998
Modified: 2025-10-01
CVE-2022-49608
In the Linux kernel, the following vulnerability has been resolved: pinctrl: ralink: Check for null return of devm_kcalloc Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.".
- https://git.kernel.org/stable/c/13596e6c9e541e90e5fc2c52b23f08b951370da9
- https://git.kernel.org/stable/c/44016a85419ca0d4f1e4d0127b330f8e4e2a57d0
- https://git.kernel.org/stable/c/5595d30c4dc27d939635c3188c68203b6ece1711
- https://git.kernel.org/stable/c/5694b162f275fb9a9f89422701b2b963be11e496
- https://git.kernel.org/stable/c/6194c021496addc11763d1ffa89ce5751889fe3c
- https://git.kernel.org/stable/c/c3b821e8e406d5650e587b7ac624ac24e9b780a8
Modified: 2025-10-01
CVE-2022-49609
In the Linux kernel, the following vulnerability has been resolved: power/reset: arm-versatile: Fix refcount leak in versatile_reboot_probe of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/493ceca3271316e74639c89ff8ac35883de64256
- https://git.kernel.org/stable/c/49fa778ee044b00471dd9ccae5f6a121fffea1ac
- https://git.kernel.org/stable/c/6689754b121bd487f99680280102b3a5cd7374af
- https://git.kernel.org/stable/c/71ab83ac65e2d671552374123bf920c1d698335a
- https://git.kernel.org/stable/c/78bdf732cf5d74d1c6ecda06830a91f80a4aef6f
- https://git.kernel.org/stable/c/80192eff64eee9b3bc0594a47381937b94b9d65a
- https://git.kernel.org/stable/c/a9ed3ad3a8d1dfbc829d86edb3236873a315db11
- https://git.kernel.org/stable/c/b4d224eec96a18fa8959512cd9e5b6a50bd16a41
Modified: 2025-10-23
CVE-2022-49610
In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Prevent RSB underflow before vmenter On VMX, there are some balanced returns between the time the guest's SPEC_CTRL value is written, and the vmenter. Balanced returns (matched by a preceding call) are usually ok, but it's at least theoretically possible an NMI with a deep call stack could empty the RSB before one of the returns. For maximum paranoia, don't allow *any* returns (balanced or otherwise) between the SPEC_CTRL write and the vmenter. [ bp: Fix 32-bit build. ]
Modified: 2025-10-23
CVE-2022-49611
In the Linux kernel, the following vulnerability has been resolved: x86/speculation: Fill RSB on vmexit for IBRS Prevent RSB underflow/poisoning attacks with RSB. While at it, add a bunch of comments to attempt to document the current state of tribal knowledge about RSB attacks and what exactly is being mitigated.
- https://git.kernel.org/stable/c/17a9fc4a7b91f8599223631bb6ae6416bc0de1c0
- https://git.kernel.org/stable/c/3d323b99ff5c8c57005184056d65f6af5b0479d8
- https://git.kernel.org/stable/c/4d7f72b6e1bc630bec7e4cd51814bc2b092bf153
- https://git.kernel.org/stable/c/8c38306e2e9257af4af2819aa287a4711ff36329
- https://git.kernel.org/stable/c/8d5cff499a6d740c91ff37963907e0e983c37f0f
- https://git.kernel.org/stable/c/9756bba28470722dacb79ffce554336dd1f6a6cd
- https://git.kernel.org/stable/c/f744b88dfc201bf8092833ec70b23c720188b527
Modified: 2025-10-23
CVE-2022-49612
In the Linux kernel, the following vulnerability has been resolved: power: supply: core: Fix boundary conditions in interpolation The functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple handle boundary conditions incorrectly. The change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283 ("power: supply: core: Use library interpolation"). There are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap have the wrong order compared to temp2resist. As a consequence, ocv2cap sets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read. Second, the logic of temp2resist is also not correct. Consider the case table[] = {{20, 100}, {10, 80}, {0, 60}}. For temp=5, we expect a resistance of 70% by interpolation. However, temp2resist sets high=low=2 and returns 60.
Modified: 2025-10-23
CVE-2022-49613
In the Linux kernel, the following vulnerability has been resolved: serial: 8250: Fix PM usage_count for console handover When console is enabled, univ8250_console_setup() calls serial8250_console_setup() before .dev is set to uart_port. Therefore, it will not call pm_runtime_get_sync(). Later, when the actual driver is going to take over univ8250_console_exit() is called. As .dev is already set, serial8250_console_exit() makes pm_runtime_put_sync() call with usage count being zero triggering PM usage count warning (extra debug for univ8250_console_setup(), univ8250_console_exit(), and serial8250_register_ports()): [ 0.068987] univ8250_console_setup ttyS0 nodev [ 0.499670] printk: console [ttyS0] enabled [ 0.717955] printk: console [ttyS0] printing thread started [ 1.960163] serial8250_register_ports assigned dev for ttyS0 [ 1.976830] printk: console [ttyS0] disabled [ 1.976888] printk: console [ttyS0] printing thread stopped [ 1.977073] univ8250_console_exit ttyS0 usage:0 [ 1.977075] serial8250 serial8250: Runtime PM usage count underflow! [ 1.977429] dw-apb-uart.6: ttyS0 at MMIO 0x4010006000 (irq = 33, base_baud = 115200) is a 16550A [ 1.977812] univ8250_console_setup ttyS0 usage:2 [ 1.978167] printk: console [ttyS0] printing thread started [ 1.978203] printk: console [ttyS0] enabled To fix the issue, call pm_runtime_get_sync() in serial8250_register_ports() as soon as .dev is set for an uart_port if it has console enabled. This problem became apparent only recently because 82586a721595 ("PM: runtime: Avoid device usage count underflows") added the warning printout. I confirmed this problem also occurs with v5.18 (w/o the warning printout, obviously).
Modified: 2025-10-01
CVE-2022-49615
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error The initial settings will be written before the codec probe function. But, the rt711->component doesn't be assigned yet. If IO error happened during initial settings operations, it will cause the kernel panic. This patch changed component->dev to slave->dev to fix this issue.
Modified: 2025-10-23
CVE-2022-49616
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt7*-sdw: harden jack_detect_handler Realtek headset codec drivers typically check if the card is instantiated before proceeding with the jack detection. The rt700, rt711 and rt711-sdca are however missing a check on the card pointer, which can lead to NULL dereferences encountered in driver bind/unbind tests.
Modified: 2025-10-23
CVE-2022-49617
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: sof_sdw: handle errors on card registration If the card registration fails, typically because of deferred probes, the device properties added for headset codecs are not removed, which leads to kernel oopses in driver bind/unbind tests. We already clean-up the device properties when the card is removed, this code can be moved as a helper and called upon card registration errors.
Modified: 2025-10-01
CVE-2022-49618
In the Linux kernel, the following vulnerability has been resolved: pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux() pdesc could be null but still dereference pdesc->name and it will lead to a null pointer access. So we move a null check before dereference.
Modified: 2025-10-01
CVE-2022-49619
In the Linux kernel, the following vulnerability has been resolved: net: sfp: fix memory leak in sfp_probe() sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When devm_add_action() fails, sfp is not freed, which leads to a memory leak. We should use devm_add_action_or_reset() instead of devm_add_action().
- https://git.kernel.org/stable/c/0a18d802d65cf662644fd1d369c86d84a5630652
- https://git.kernel.org/stable/c/1545bc727625ea6e8decd717e5d1e8cc704ccf8f
- https://git.kernel.org/stable/c/204543581a2f26bb3b997a304c0bd06926ba7f15
- https://git.kernel.org/stable/c/67dc32542a1fb7790d0853cf4a5cf859ac6a2002
- https://git.kernel.org/stable/c/9ec5a97f327a89031fce6cfc3e95543c53936638
- https://git.kernel.org/stable/c/ede990cfc42775bd0141e21f37ee365dcaeeb50f
- https://git.kernel.org/stable/c/f22ddc8a5278d7fb6369a0aeb0d8775a0aefaaee
Modified: 2025-10-01
CVE-2022-49620
In the Linux kernel, the following vulnerability has been resolved: net: tipc: fix possible refcount leak in tipc_sk_create() Free sk in case tipc_sk_insert() fails.
- https://git.kernel.org/stable/c/00aff3590fc0a73bddd3b743863c14e76fd35c0c
- https://git.kernel.org/stable/c/3b2957fc09fe1ac7f07f40dd50dd5f93e3f3a7a2
- https://git.kernel.org/stable/c/4919d82f7041157a421ca9bf39a78551d5ad8a1b
- https://git.kernel.org/stable/c/638fa20b618b2bbcf86da71231624cc82121a036
- https://git.kernel.org/stable/c/7bc9e7f70bc57d8f02ffea2a42094281effb15ef
- https://git.kernel.org/stable/c/833ecd0eae76eadf81d6d747bb5bc992d1151867
- https://git.kernel.org/stable/c/ef488669b2652bde5b6ee5a409a5b048a2a50db4
- https://git.kernel.org/stable/c/efa78f2ae363428525fb4981bb63c555ee79f3c7
Modified: 2025-10-01
CVE-2022-49621
In the Linux kernel, the following vulnerability has been resolved: cpufreq: pmac32-cpufreq: Fix refcount leak bug In pmac_cpufreq_init_MacRISC3(), we need to add corresponding of_node_put() for the three node pointers whose refcount have been incremented by of_find_node_by_name().
- https://git.kernel.org/stable/c/37c16fc2cb13a13f3c0193bfc6f2edef7d7df7d7
- https://git.kernel.org/stable/c/3ea9dbf7c2f436952bca331c6f5d72f75aca224e
- https://git.kernel.org/stable/c/4513018d0bd739097570d26a7760551cba3deb56
- https://git.kernel.org/stable/c/4585890ab2dbf455d80e254d3d859d4c1e357920
- https://git.kernel.org/stable/c/4f242486bf46d314b2e3838cc64b56f008a3c4d7
- https://git.kernel.org/stable/c/57289b6601fe78c09921599b042a0b430fb420ec
- https://git.kernel.org/stable/c/8dda30f81c751b01cd71f2cfaeef26ad4393b1d1
- https://git.kernel.org/stable/c/ccd7567d4b6cf187fdfa55f003a9e461ee629e36
Modified: 2025-03-24
CVE-2022-49622
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid skb access on nf_stolen When verdict is NF_STOLEN, the skb might have been freed. When tracing is enabled, this can result in a use-after-free: 1. access to skb->nf_trace 2. access to skb->mark 3. computation of trace id 4. dump of packet payload To avoid 1, keep a cached copy of skb->nf_trace in the trace state struct. Refresh this copy whenever verdict is != STOLEN. Avoid 2 by skipping skb->mark access if verdict is STOLEN. 3 is avoided by precomputing the trace id. Only dump the packet when verdict is not "STOLEN".
Modified: 2025-10-01
CVE-2022-49623
In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency.
Modified: 2025-10-23
CVE-2022-49624
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: remove aq_nic_deinit() when resume
aq_nic_deinit() has been called while suspending, so we don't have to call
it again on resume.
Actually, call it again leads to another hang issue when resuming from
S3.
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992345] Call Trace:
Jul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992346]
Modified: 2025-10-23
CVE-2022-49625
In the Linux kernel, the following vulnerability has been resolved: sfc: fix kernel panic when creating VF When creating VFs a kernel panic can happen when calling to efx_ef10_try_update_nic_stats_vf. When releasing a DMA coherent buffer, sometimes, I don't know in what specific circumstances, it has to unmap memory with vunmap. It is disallowed to do that in IRQ context or with BH disabled. Otherwise, we hit this line in vunmap, causing the crash: BUG_ON(in_interrupt()); This patch reenables BH to release the buffer. Log messages when the bug is hit: kernel BUG at mm/vmalloc.c:2727! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G I --------- --- 5.14.0-119.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020 RIP: 0010:vunmap+0x2e/0x30 ...skip... Call Trace: __iommu_dma_free+0x96/0x100 efx_nic_free_buffer+0x2b/0x40 [sfc] efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc] efx_ef10_update_stats_vf+0x18/0x40 [sfc] efx_start_all+0x15e/0x1d0 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xe7/0x1a0 __dev_change_flags+0x1d7/0x240 dev_change_flags+0x21/0x60 ...skip...
- https://git.kernel.org/stable/c/16662524ec5da801fb78a1afcaf6e782f1cf103a
- https://git.kernel.org/stable/c/68e5f32f0de9594629ff9e599294d9801c6187de
- https://git.kernel.org/stable/c/82bcb730f856086f033e6c04082eb4503d4c2fa4
- https://git.kernel.org/stable/c/ada74c5539eba06cf8b47d068f92e0b3963a9a6e
- https://git.kernel.org/stable/c/b82e4ad58a7fb72456503958a93060f87896e629
- https://git.kernel.org/stable/c/b9072305270579a9d6afc9b926166231e5b1a7c8
- https://git.kernel.org/stable/c/d9840212a9c00507347c703f4fdeda16400407e0
- https://git.kernel.org/stable/c/da346adcf5573fd8663cabfdfe8371009629a906
Modified: 2025-03-24
CVE-2022-49626
In the Linux kernel, the following vulnerability has been resolved: sfc: fix use after free when disabling sriov Use after free is detected by kfence when disabling sriov. What was read after being freed was vf->pci_dev: it was freed from pci_disable_sriov and later read in efx_ef10_sriov_free_vf_vports, called from efx_ef10_sriov_free_vf_vswitching. Set the pointer to NULL at release time to not trying to read it later. Reproducer and dmesg log (note that kfence doesn't detect it every time): $ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs $ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
- https://git.kernel.org/stable/c/3199e34912d84cdfb8a93a984c5ae5c73fb13e84
- https://git.kernel.org/stable/c/58d93e9d160c0de6d867c7eb4c2206671a351eb1
- https://git.kernel.org/stable/c/9c854ae512b89229aeee93849e9bd4c115b37909
- https://git.kernel.org/stable/c/bcad880865bfb421885364b1f0c7351280fe2b97
- https://git.kernel.org/stable/c/c2240500817b3b4b996cdf2a461a3a5679f49b94
- https://git.kernel.org/stable/c/c9e75bb22a26e391f189f5a5133dd63dcb57fdaa
- https://git.kernel.org/stable/c/e435c4aeeaa073091f7f3b7735af2ef5c97d63f2
- https://git.kernel.org/stable/c/ebe41da5d47ac0fff877e57bd14c54dccf168827
Modified: 2025-10-01
CVE-2022-49627
In the Linux kernel, the following vulnerability has been resolved: ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak.
Modified: 2025-10-23
CVE-2022-49628
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix leaks in probe These two error paths should clean up before returning.
Modified: 2025-10-01
CVE-2022-49629
In the Linux kernel, the following vulnerability has been resolved: nexthop: Fix data-races around nexthop_compat_mode. While reading nexthop_compat_mode, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49630
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_ecn_fallback. While reading sysctl_tcp_ecn_fallback, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
Modified: 2025-10-01
CVE-2022-49631
In the Linux kernel, the following vulnerability has been resolved: raw: Fix a data-race around sysctl_raw_l3mdev_accept. While reading sysctl_raw_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
- https://git.kernel.org/stable/c/038a87b3e460d2ee579c8b1bd3890d816d6687b1
- https://git.kernel.org/stable/c/1dace014928e6e385363032d359a04dee9158af0
- https://git.kernel.org/stable/c/46e9c46203fd4676720ddca0fef7eff26826648e
- https://git.kernel.org/stable/c/ab5adca2e17d6595f3fc0e25ccb6bcbe2e01ca4f
- https://git.kernel.org/stable/c/cc9540ba5b3652c473af7e54892a48cdced87983
Modified: 2025-10-01
CVE-2022-49632
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix a data-race around sysctl_icmp_errors_use_inbound_ifaddr. While reading sysctl_icmp_errors_use_inbound_ifaddr, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader.
Modified: 2025-10-01
CVE-2022-49633
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix data-races around sysctl_icmp_echo_enable_probe. While reading sysctl_icmp_echo_enable_probe, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers.
Modified: 2025-10-01
CVE-2022-49634
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data-races in proc_dou8vec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_dou8vec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_dou8vec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.
Modified: 2025-10-23
CVE-2022-49635
In the Linux kernel, the following vulnerability has been resolved: drm/i915/selftests: fix subtraction overflow bug On some machines hole_end can be small enough to cause subtraction overflow. On the other side (addr + 2 * min_alignment) can overflow in case of mock tests. This patch should handle both cases. (cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)
Modified: 2025-04-10
CVE-2022-49636
In the Linux kernel, the following vulnerability has been resolved:
vlan: fix memory leak in vlan_newlink()
Blamed commit added back a bug I fixed in commit 9bbd917e0bec
("vlan: fix memory leak in vlan_dev_set_egress_priority")
If a memory allocation fails in vlan_changelink() after other allocations
succeeded, we need to call vlan_dev_free_egress_priority()
to free all allocated memory because after a failed ->newlink()
we do not call any methods like ndo_uninit() or dev->priv_destructor().
In following example, if the allocation for last element 2000:2001 fails,
we need to free eight prior allocations:
ip link add link dummy0 dummy0.100 type vlan id 100 \
egress-qos-map 1:2 2:3 3:4 4:5 5:6 6:7 7:8 8:9 2000:2001
syzbot report was:
BUG: memory leak
unreferenced object 0xffff888117bd1060 (size 32):
comm "syz-executor408", pid 3759, jiffies 4294956555 (age 34.090s)
hex dump (first 32 bytes):
09 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/4c43069bb1097dd6cc1cf0f7c43a36d1f7b3910b
- https://git.kernel.org/stable/c/549de58dba4bf1b2adc72e9948b9c76fa88be9d2
- https://git.kernel.org/stable/c/72a0b329114b1caa8e69dfa7cdad1dd3c69b8602
- https://git.kernel.org/stable/c/df27729a4fe0002dfd80c96fe1c142829c672728
- https://git.kernel.org/stable/c/f5dc10b910bdac523e5947336445a77066c51bf9
Modified: 2025-10-01
CVE-2022-49637
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix a data-race around sysctl_fib_sync_mem. While reading sysctl_fib_sync_mem, it can be changed concurrently. So, we need to add READ_ONCE() to avoid a data-race.
- https://git.kernel.org/stable/c/190cd4ff128373271e065afb20f1d2247b3f10c3
- https://git.kernel.org/stable/c/418b191d5f223a8cb6cab09eae1f72c04ba6adf2
- https://git.kernel.org/stable/c/73318c4b7dbd0e781aaababff17376b2894745c0
- https://git.kernel.org/stable/c/7c1acd98fb221dc0d847451b9ab86319f8b9916c
- https://git.kernel.org/stable/c/9be8aac91960ea32fd0e874758c9afee665c57d2
Modified: 2025-10-01
CVE-2022-49638
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix data-races around sysctl. While reading icmp sysctl variables, they can be changed concurrently. So, we need to add READ_ONCE() to avoid data-races.
- https://git.kernel.org/stable/c/0cba7ca667ceb06934746ddd9833a25847bde81d
- https://git.kernel.org/stable/c/1740e5922fbb705637ae9fa5203db132fc45f9f6
- https://git.kernel.org/stable/c/48d7ee321ea5182c6a70782aa186422a70e67e22
- https://git.kernel.org/stable/c/53ecd09ef2fb35fa69667ae8e414ef6b00fd3bf6
- https://git.kernel.org/stable/c/798c2cf57c63ab39c8aac24d6a3d50f4fa5eeb06
- https://git.kernel.org/stable/c/e088ceb73c24ab4774da391d54a6426f4bfaefce
- https://git.kernel.org/stable/c/e2828e8c605853f71267825c9415437c0a93e4f2
- https://git.kernel.org/stable/c/edeec63b13c252193d626c2a48d7a2f0e7016dc2
Modified: 2025-10-01
CVE-2022-49639
In the Linux kernel, the following vulnerability has been resolved: cipso: Fix data-races around sysctl. While reading cipso sysctl variables, they can be changed concurrently. So, we need to add READ_ONCE() to avoid data-races.
- https://git.kernel.org/stable/c/07b0caf8aeb9b82e6ecc6c292a3e47c7fcdb1148
- https://git.kernel.org/stable/c/0e41a0f73ccb9be112a80bde3804a771633caaef
- https://git.kernel.org/stable/c/2764f82bbc158d106693ae3ced3675cf4b963b35
- https://git.kernel.org/stable/c/59e26906b89cc35bb54476498772b45cbc32323f
- https://git.kernel.org/stable/c/c321e99d2725d11f7e6a4ebd9ce752259f0bae81
- https://git.kernel.org/stable/c/ca26ca5e2f3eeb3e6fe699cd6effa3b4b2aa8698
- https://git.kernel.org/stable/c/dd44f04b9214adb68ef5684ae87a81ba03632250
- https://git.kernel.org/stable/c/fe2a35fa2c4f9c8ce5ef970eb927031387f9446a
Modified: 2025-10-01
CVE-2022-49640
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.
Modified: 2025-10-01
CVE-2022-49641
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side.
Modified: 2025-10-23
CVE-2022-49642
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: dwc-qos: Disable split header for Tegra194 There is a long-standing issue with the Synopsys DWC Ethernet driver for Tegra194 where random system crashes have been observed [0]. The problem occurs when the split header feature is enabled in the stmmac driver. In the bad case, a larger than expected buffer length is received and causes the calculation of the total buffer length to overflow. This results in a very large buffer length that causes the kernel to crash. Why this larger buffer length is received is not clear, however, the feedback from the NVIDIA design team is that the split header feature is not supported for Tegra194. Therefore, disable split header support for Tegra194 to prevent these random crashes from occurring. [0] https://lore.kernel.org/linux-tegra/b0b17697-f23e-8fa5-3757-604a86f3a095@nvidia.com/
- https://git.kernel.org/stable/c/029c1c2059e9c4b38f97a06204cdecd10cfbeb8a
- https://git.kernel.org/stable/c/2968830c9b47ce093237483c6207c61065712386
- https://git.kernel.org/stable/c/9cc8edc571b871d974b3289868553f9ce544aba6
- https://git.kernel.org/stable/c/cfa4caf3e881ad6dd366c903c34f1c7f21b857ab
- https://git.kernel.org/stable/c/d5c315a787652c35045044877a249f7d5c8a4104
Modified: 2025-10-01
CVE-2022-49643
In the Linux kernel, the following vulnerability has been resolved: ima: Fix a potential integer overflow in ima_appraise_measurement When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be negative, which may cause the integer overflow problem.
- https://git.kernel.org/stable/c/388f3df7c3c8b7f2a32b9ae0a9b2f9f6ad3b1b77
- https://git.kernel.org/stable/c/640cea4c2839a821adfbb703b590a5928abe9286
- https://git.kernel.org/stable/c/831e190175f10652be93b08436cc7bf2e62e4bb6
- https://git.kernel.org/stable/c/c8d5d81940938b5f6c0f495ca9538e7740416f30
- https://git.kernel.org/stable/c/d2ee2cfc4aa85ff6a2a3b198a3a524ec54e3d999
Modified: 2025-10-01
CVE-2022-49644
In the Linux kernel, the following vulnerability has been resolved: drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector() If drm_connector_init fails, intel_connector_free will be called to take care of proper free. So it is necessary to drop the refcount of port before intel_connector_free. (cherry picked from commit cea9ed611e85d36a05db52b6457bf584b7d969e2)
- https://git.kernel.org/stable/c/505114dda5bbfd07f4ce9a2df5b7d8ef5f2a1218
- https://git.kernel.org/stable/c/592f3bad00b7e2a95a6fb7a4f9e742c061c9c3c1
- https://git.kernel.org/stable/c/72f231b9a88abcfac9f5ddaa1a0aacb3f9f87ba5
- https://git.kernel.org/stable/c/85144df9ff4652816448369de76897c57cbb1b93
- https://git.kernel.org/stable/c/a91522b4279bebb098106a19b91f82b9c3213be9
Modified: 2025-10-23
CVE-2022-49645
In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix shrinker list corruption by madvise IOCTL Calling madvise IOCTL twice on BO causes memory shrinker list corruption and crashes kernel because BO is already on the list and it's added to the list again, while BO should be removed from the list before it's re-added. Fix it.
- https://git.kernel.org/stable/c/0581613df7f9a4c5fac096ce1d5fb15b7b994240
- https://git.kernel.org/stable/c/1807d8867402a58b831a7fc16832747ff559a0d1
- https://git.kernel.org/stable/c/393594aad55179eb761af41533d8d1d6eb4543b0
- https://git.kernel.org/stable/c/9fc33eaaa979d112d10fea729edcd2a2e21aa912
- https://git.kernel.org/stable/c/f036392edd9c49090781d8cca26ad6557a63bae4
Modified: 2025-10-23
CVE-2022-49646
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix queue selection for mesh/OCB interfaces When using iTXQ, the code assumes that there is only one vif queue for broadcast packets, using the BE queue. Allowing non-BE queue marking violates that assumption and txq->ac == skb_queue_mapping is no longer guaranteed. This can cause issues with queue handling in the driver and also causes issues with the recent ATF change, resulting in an AQL underflow warning.
- https://git.kernel.org/stable/c/41ecab279a70dced9005f4d55fa0fcde8938603f
- https://git.kernel.org/stable/c/444be5a02b77f3b7a8ac9c1a0b074fbb3bd89cd0
- https://git.kernel.org/stable/c/50e2ab39291947b6c6c7025cf01707c270fcde59
- https://git.kernel.org/stable/c/5a9df31017999197b6e60535940f2f2fe1bd3b0d
- https://git.kernel.org/stable/c/e013ea2a51a94b903b396a8dff531a07d470335d
Modified: 2025-03-24
CVE-2022-49647
In the Linux kernel, the following vulnerability has been resolved: cgroup: Use separate src/dst nodes when preloading css_sets for migration Each cset (css_set) is pinned by its tasks. When we're moving tasks around across csets for a migration, we need to hold the source and destination csets to ensure that they don't go away while we're moving tasks about. This is done by linking cset->mg_preload_node on either the mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the same cset->mg_preload_node for both the src and dst lists was deemed okay as a cset can't be both the source and destination at the same time. Unfortunately, this overloading becomes problematic when multiple tasks are involved in a migration and some of them are identity noop migrations while others are actually moving across cgroups. For example, this can happen with the following sequence on cgroup1: #1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs the process including the group leader back into a. In this final migration, non-leader threads would be doing identity migration while the group leader is doing an actual one. After #3, let's say the whole process was in cset A, and that after #4, the leader moves to cset B. Then, during #6, the following happens: 1. cgroup_migrate_add_src() is called on B for the leader. 2. cgroup_migrate_add_src() is called on A for the other threads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mg_preload_node is already busy. 5. and then it notices A wants to migrate to A as it's an identity migration, it culls it by list_del_init()'ing its ->mg_preload_node and putting references accordingly. 6. The rest of migration takes place with B on the src list but nothing on the dst list. This means that A isn't held while migration is in progress. If all tasks leave A before the migration finishes and the incoming task pins it, the cset will be destroyed leading to use-after-free. This is caused by overloading cset->mg_preload_node for both src and dst preload lists. We wanted to exclude the cset from the src list but ended up inadvertently excluding it from the dst list too. This patch fixes the issue by separating out cset->mg_preload_node into ->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst preloadings don't interfere with each other.
- https://git.kernel.org/stable/c/05f7658210d1d331e8dd4cb6e7bbbe3df5f5ac27
- https://git.kernel.org/stable/c/07fd5b6cdf3cc30bfde8fe0f644771688be04447
- https://git.kernel.org/stable/c/0e41774b564befa6d271e8d5086bf870d617a4e6
- https://git.kernel.org/stable/c/54aee4e5ce8c21555286a6333e46c1713880cf93
- https://git.kernel.org/stable/c/7657e3958535d101a24ab4400f9b8062b9107cc4
- https://git.kernel.org/stable/c/ad44e05f3e016bdcb1ad25af35ade5b5f41ccd68
- https://git.kernel.org/stable/c/cec2bbdcc14fbaa6b95ee15a7c423b05d97038be
Modified: 2025-10-01
CVE-2022-49648
In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th var_defs.name" is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/22eeff55679d9e7c0f768c79bfbd83e2f8142d89
- https://git.kernel.org/stable/c/4d453eb5e1eec89971aa5b3262857ee26cfdffd3
- https://git.kernel.org/stable/c/78a1400c42ee11197eb1f0f85ba51df9a4fdfff0
- https://git.kernel.org/stable/c/7edc3945bdce9c39198a10d6129377a5c53559c2
- https://git.kernel.org/stable/c/eb622d5580b9e2ff694f62da6410618bd73853cb
- https://git.kernel.org/stable/c/ecc6dec12c33aa92c086cd702af9f544ddaf3c75
Modified: 2025-10-01
CVE-2022-49649
In the Linux kernel, the following vulnerability has been resolved: xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue xenvif_rx_next_skb() is expecting the rx queue not being empty, but in case the loop in xenvif_rx_action() is doing multiple iterations, the availability of another skb in the rx queue is not being checked. This can lead to crashes: [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.537534] PGD 0 P4D 0 [40072.537644] Oops: 0000 [#1] SMP NOPTI [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5 [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021 [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000 [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246 [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7 [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8 [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008 [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708 [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0 [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000 [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660 [40072.539211] Call Trace: [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback] [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback] Fix that by stopping the loop in case the rx queue becomes empty.
- https://git.kernel.org/stable/c/5a071aefd6414af5a20321ab58a0557b81993687
- https://git.kernel.org/stable/c/7425479d20f9e96f7c3ec8e8a93fe0d7478724cb
- https://git.kernel.org/stable/c/94e8100678889ab428e68acadf042de723f094b9
- https://git.kernel.org/stable/c/b99174ac57fe5d8867448c03b23828e63f24cb1c
- https://git.kernel.org/stable/c/b9c32a6886af79d6e0ad87a7b01800ed079cdd02
- https://git.kernel.org/stable/c/c0fcceb5f3f1ec197c014fe218c2f28108cacd27
- https://git.kernel.org/stable/c/d5320c6a27aa975aff740f9cb481dcbde48f4348
- https://git.kernel.org/stable/c/f0b5c819b062df8bf5f2acf4697e3871cb3722da
Package kernel-image-un-def updated to version 5.18.16-alt1 for branch sisyphus in task 304716.
Closed vulnerabilities
Modified: 2024-09-30
BDU:2022-04686
Уязвимость модуля nfnetlink_queue ядра операционных систем Linux, связанная с некорректной обработкой вердиктов с однобайтным атрибутом nfta_payload, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-05
CVE-2022-36946
nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte nfta_payload attribute, an skb_pull can encounter a negative skb->len.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://marc.info/?l=netfilter-devel&m=165883202007292&w=2
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://marc.info/?l=netfilter-devel&m=165883202007292&w=2
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
Package docs-alt-workstation updated to version 10.1-alt2 for branch sisyphus in task 304733.
Closed bugs
Документация docs-alt-workstation - Опечатка в частице "то"
Документация docs-alt-workstation пункт 35.3. Центр приложений - Нет выделения для названия кнопки дополнительных сведений
Документация docs-alt-workstation пункт 35.3. Центр приложений - опечатки
Документация docs-alt-workstation пункт 34.2. Xsane - опечатки
Документация docs-alt-workstation пункт 34.2. Xsane - в поле "Назначение" нет значений "Файл", "Просмотр"
Package kernel-image-std-def updated to version 5.15.59-alt1 for branch sisyphus in task 304730.
Closed vulnerabilities
Modified: 2024-09-30
BDU:2022-04686
Уязвимость модуля nfnetlink_queue ядра операционных систем Linux, связанная с некорректной обработкой вердиктов с однобайтным атрибутом nfta_payload, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-05
CVE-2022-36946
nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte nfta_payload attribute, an skb_pull can encounter a negative skb->len.
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://marc.info/?l=netfilter-devel&m=165883202007292&w=2
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164
- https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://marc.info/?l=netfilter-devel&m=165883202007292&w=2
- https://security.netapp.com/advisory/ntap-20220901-0007/
- https://www.debian.org/security/2022/dsa-5207
Modified: 2025-10-01
CVE-2022-49589
In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_qrv. While reading sysctl_igmp_qrv, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);
- https://git.kernel.org/stable/c/8ebcc62c738f68688ee7c6fec2efe5bc6d3d7e60
- https://git.kernel.org/stable/c/9eeb3a7702998bdccbfcc37997b5dd9215b9a7f7
- https://git.kernel.org/stable/c/b399ffafffba39f47b731b26a5da1dc0ffc4b3ad
- https://git.kernel.org/stable/c/c2954671010cd1127d1ffa328c6e6f8e99930982
- https://git.kernel.org/stable/c/c721324afc589f8ea54bae04756b150aeaae5fa4
- https://git.kernel.org/stable/c/e20dd1b0e0ea15bee1e528536a0840dba972ca0e
Closed bugs
Missing node-gyp
Package java-11-openjdk updated to version 11.0.16.0.8-alt1_1jpp11 for branch sisyphus in task 304693.
Closed vulnerabilities
Modified: 2025-06-09
BDU:2022-04788
Уязвимость библиотеки Apache Xalan Java XSLT, связанная с ошибкой приведения целочисленного значения, позволяющая нарушителю выполнить произвольный код
Modified: 2025-06-09
BDU:2022-05103
Уязвимость компонента Hotspot программных платформ Java SE, виртуальной машины Oracle GraalVM Enterprise Edition, позволяющая нарушителю создавать, удалять или изменять доступ к данным
Modified: 2025-06-09
BDU:2022-05104
Уязвимость компонента Hotspot программных платформ Java SE, виртуальной машины Oracle GraalVM Enterprise Edition, позволяющая нарушителю получить доступ на чтение данных
Modified: 2024-11-21
CVE-2022-21540
Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 7u343, 8u333, 11.0.15.1, 17.0.3.1, 18.0.1.1; Oracle GraalVM Enterprise Edition: 20.3.6, 21.3.2 and 22.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N).
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2022-21541
Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 7u343, 8u333, 11.0.15.1, 17.0.3.1, 18.0.1.1; Oracle GraalVM Enterprise Edition: 20.3.6, 21.3.2 and 22.1.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2022-34169
The Apache Xalan Java XSLT library is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. This can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode. Users are recommended to update to version 2.7.3 or later. Note: Java runtimes (such as OpenJDK) include repackaged copies of Xalan.
- http://packetstormsecurity.com/files/168186/Xalan-J-XSLTC-Integer-Truncation.html
- http://www.openwall.com/lists/oss-security/2022/07/19/5
- http://www.openwall.com/lists/oss-security/2022/07/19/6
- http://www.openwall.com/lists/oss-security/2022/07/20/2
- http://www.openwall.com/lists/oss-security/2022/07/20/3
- http://www.openwall.com/lists/oss-security/2022/10/18/2
- http://www.openwall.com/lists/oss-security/2022/11/04/8
- http://www.openwall.com/lists/oss-security/2022/11/07/2
- https://lists.apache.org/thread/12pxy4phsry6c34x2ol4fft6xlho4kyw
- https://lists.apache.org/thread/2qvl7r43wb4t8p9dd9om1bnkssk07sn8
- https://lists.debian.org/debian-lts-announce/2022/10/msg00024.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://security.netapp.com/advisory/ntap-20240621-0006/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.debian.org/security/2022/dsa-5256
- https://www.oracle.com/security-alerts/cpujul2022.html
- http://packetstormsecurity.com/files/168186/Xalan-J-XSLTC-Integer-Truncation.html
- http://www.openwall.com/lists/oss-security/2022/07/19/5
- http://www.openwall.com/lists/oss-security/2022/07/19/6
- http://www.openwall.com/lists/oss-security/2022/07/20/2
- http://www.openwall.com/lists/oss-security/2022/07/20/3
- http://www.openwall.com/lists/oss-security/2022/10/18/2
- http://www.openwall.com/lists/oss-security/2022/11/04/8
- http://www.openwall.com/lists/oss-security/2022/11/07/2
- https://lists.apache.org/thread/12pxy4phsry6c34x2ol4fft6xlho4kyw
- https://lists.apache.org/thread/2qvl7r43wb4t8p9dd9om1bnkssk07sn8
- https://lists.debian.org/debian-lts-announce/2022/10/msg00024.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://security.netapp.com/advisory/ntap-20240621-0006/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.debian.org/security/2022/dsa-5256
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-06-25
GHSA-9339-86wc-4qgf
Apache Xalan Java XSLT library integer truncation issue when processing malicious XSLT stylesheets
- https://nvd.nist.gov/vuln/detail/CVE-2022-34169
- https://xalan.apache.org
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://www.debian.org/security/2022/dsa-5256
- https://www.debian.org/security/2022/dsa-5192
- https://www.debian.org/security/2022/dsa-5188
- https://security.netapp.com/advisory/ntap-20240621-0006
- https://security.netapp.com/advisory/ntap-20220729-0009
- https://security.gentoo.org/glsa/202401-25
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L
- https://lists.debian.org/debian-lts-announce/2022/10/msg00024.html
- https://lists.apache.org/thread/x3f7xv3p1g32qj2hlg8wd57pwcpld471
- https://lists.apache.org/thread/2qvl7r43wb4t8p9dd9om1bnkssk07sn8
- https://lists.apache.org/thread/12pxy4phsry6c34x2ol4fft6xlho4kyw
- https://gitbox.apache.org/repos/asf?p=xalan-java.git;a=commit;h=da3e0d06b467247643ce04e88d3346739d119f21
- https://gitbox.apache.org/repos/asf?p=xalan-java.git;a=commit;h=ab57211e5d2e97cbed06786f919fa9b749c83573
- https://gitbox.apache.org/repos/asf?p=xalan-java.git;a=commit;h=2e60d0a9a5b822c4abf9051857973b1c6babfe81
- https://gitbox.apache.org/repos/asf?p=xalan-java.git
- http://packetstormsecurity.com/files/168186/Xalan-J-XSLTC-Integer-Truncation.html
- http://www.openwall.com/lists/oss-security/2022/07/19/5
- http://www.openwall.com/lists/oss-security/2022/07/19/6
- http://www.openwall.com/lists/oss-security/2022/07/20/2
- http://www.openwall.com/lists/oss-security/2022/07/20/3
- http://www.openwall.com/lists/oss-security/2022/10/18/2
- http://www.openwall.com/lists/oss-security/2022/11/04/8
- http://www.openwall.com/lists/oss-security/2022/11/07/2
Package java-1.8.0-openjdk updated to version 1.8.0.342.b07-alt0_0.1.eajpp8 for branch sisyphus in task 304691.
Closed vulnerabilities
Modified: 2025-06-09
BDU:2022-04788
Уязвимость библиотеки Apache Xalan Java XSLT, связанная с ошибкой приведения целочисленного значения, позволяющая нарушителю выполнить произвольный код
Modified: 2025-06-09
BDU:2022-05103
Уязвимость компонента Hotspot программных платформ Java SE, виртуальной машины Oracle GraalVM Enterprise Edition, позволяющая нарушителю создавать, удалять или изменять доступ к данным
Modified: 2025-06-09
BDU:2022-05104
Уязвимость компонента Hotspot программных платформ Java SE, виртуальной машины Oracle GraalVM Enterprise Edition, позволяющая нарушителю получить доступ на чтение данных
Modified: 2024-11-21
CVE-2022-21540
Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 7u343, 8u333, 11.0.15.1, 17.0.3.1, 18.0.1.1; Oracle GraalVM Enterprise Edition: 20.3.6, 21.3.2 and 22.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N).
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2022-21541
Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 7u343, 8u333, 11.0.15.1, 17.0.3.1, 18.0.1.1; Oracle GraalVM Enterprise Edition: 20.3.6, 21.3.2 and 22.1.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-11-21
CVE-2022-34169
The Apache Xalan Java XSLT library is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. This can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode. Users are recommended to update to version 2.7.3 or later. Note: Java runtimes (such as OpenJDK) include repackaged copies of Xalan.
- http://packetstormsecurity.com/files/168186/Xalan-J-XSLTC-Integer-Truncation.html
- http://www.openwall.com/lists/oss-security/2022/07/19/5
- http://www.openwall.com/lists/oss-security/2022/07/19/6
- http://www.openwall.com/lists/oss-security/2022/07/20/2
- http://www.openwall.com/lists/oss-security/2022/07/20/3
- http://www.openwall.com/lists/oss-security/2022/10/18/2
- http://www.openwall.com/lists/oss-security/2022/11/04/8
- http://www.openwall.com/lists/oss-security/2022/11/07/2
- https://lists.apache.org/thread/12pxy4phsry6c34x2ol4fft6xlho4kyw
- https://lists.apache.org/thread/2qvl7r43wb4t8p9dd9om1bnkssk07sn8
- https://lists.debian.org/debian-lts-announce/2022/10/msg00024.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://security.netapp.com/advisory/ntap-20240621-0006/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.debian.org/security/2022/dsa-5256
- https://www.oracle.com/security-alerts/cpujul2022.html
- http://packetstormsecurity.com/files/168186/Xalan-J-XSLTC-Integer-Truncation.html
- http://www.openwall.com/lists/oss-security/2022/07/19/5
- http://www.openwall.com/lists/oss-security/2022/07/19/6
- http://www.openwall.com/lists/oss-security/2022/07/20/2
- http://www.openwall.com/lists/oss-security/2022/07/20/3
- http://www.openwall.com/lists/oss-security/2022/10/18/2
- http://www.openwall.com/lists/oss-security/2022/11/04/8
- http://www.openwall.com/lists/oss-security/2022/11/07/2
- https://lists.apache.org/thread/12pxy4phsry6c34x2ol4fft6xlho4kyw
- https://lists.apache.org/thread/2qvl7r43wb4t8p9dd9om1bnkssk07sn8
- https://lists.debian.org/debian-lts-announce/2022/10/msg00024.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB/
- https://security.gentoo.org/glsa/202401-25
- https://security.netapp.com/advisory/ntap-20220729-0009/
- https://security.netapp.com/advisory/ntap-20240621-0006/
- https://www.debian.org/security/2022/dsa-5188
- https://www.debian.org/security/2022/dsa-5192
- https://www.debian.org/security/2022/dsa-5256
- https://www.oracle.com/security-alerts/cpujul2022.html
Modified: 2024-06-25
GHSA-9339-86wc-4qgf
Apache Xalan Java XSLT library integer truncation issue when processing malicious XSLT stylesheets
- https://nvd.nist.gov/vuln/detail/CVE-2022-34169
- https://xalan.apache.org
- https://www.oracle.com/security-alerts/cpujul2022.html
- https://www.debian.org/security/2022/dsa-5256
- https://www.debian.org/security/2022/dsa-5192
- https://www.debian.org/security/2022/dsa-5188
- https://security.netapp.com/advisory/ntap-20240621-0006
- https://security.netapp.com/advisory/ntap-20220729-0009
- https://security.gentoo.org/glsa/202401-25
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YULPNO3PAWMEQQZV2C54I3H3ZOXFZUTB
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/L3XPOTPPBZIPFBZHQE5E7OW6PDACUMCJ
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KO3DXNKZ4EU3UZBT6AAR4XRKCD73KLMO
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JN3EVGR7FD3ZLV5SBTJXUIDCMSK4QUE2
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/I5OZNAZJ4YHLOKRRRZSWRT5OJ25E4XLM
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H4YNJSJ64NPCNKFPNBYITNZU5H3L4D6L
- https://lists.debian.org/debian-lts-announce/2022/10/msg00024.html
- https://lists.apache.org/thread/x3f7xv3p1g32qj2hlg8wd57pwcpld471
- https://lists.apache.org/thread/2qvl7r43wb4t8p9dd9om1bnkssk07sn8
- https://lists.apache.org/thread/12pxy4phsry6c34x2ol4fft6xlho4kyw
- https://gitbox.apache.org/repos/asf?p=xalan-java.git;a=commit;h=da3e0d06b467247643ce04e88d3346739d119f21
- https://gitbox.apache.org/repos/asf?p=xalan-java.git;a=commit;h=ab57211e5d2e97cbed06786f919fa9b749c83573
- https://gitbox.apache.org/repos/asf?p=xalan-java.git;a=commit;h=2e60d0a9a5b822c4abf9051857973b1c6babfe81
- https://gitbox.apache.org/repos/asf?p=xalan-java.git
- http://packetstormsecurity.com/files/168186/Xalan-J-XSLTC-Integer-Truncation.html
- http://www.openwall.com/lists/oss-security/2022/07/19/5
- http://www.openwall.com/lists/oss-security/2022/07/19/6
- http://www.openwall.com/lists/oss-security/2022/07/20/2
- http://www.openwall.com/lists/oss-security/2022/07/20/3
- http://www.openwall.com/lists/oss-security/2022/10/18/2
- http://www.openwall.com/lists/oss-security/2022/11/04/8
- http://www.openwall.com/lists/oss-security/2022/11/07/2
Package kernel-image-xenomai updated to version 4.19.252-alt1.cip78.23 for branch sisyphus in task 304715.
Closed vulnerabilities
Modified: 2023-11-13
BDU:2022-03283
Уязвимость функции nft_expr_init программного обеспечения фильтрации пакетов Netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии до уровня root
Modified: 2025-08-19
BDU:2022-03704
Уязвимость функции dx_insert_block() (fs/ext4/namei.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-04269
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-30
BDU:2022-04270
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-04272
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-09-30
BDU:2022-04876
Уязвимость кроссплатформенного гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04337
Уязвимость функции nfc_unregister_device() модуля net/nfc/core.c подсистемы NFC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-04355
Уязвимость функции radeon_fp_native_mode() модуля drivers/gpu/drm/radeon/radeon_connectors.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-04416
Уязвимость функции ___slab_alloc() модуля mm/slub.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04420
Уязвимость функции bond_3ad_unbind_slave() модуля drivers/net/bonding/bond_3ad.c - драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04424
Уязвимость функции cx23885_initdev() модуля drivers/media/pci/cx23885/cx23885-core.c - драйвера поддержки мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04425
Уязвимость функции rt5645_i2c_remove() модуля sound/soc/codecs/rt5645.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2025-04426
Уязвимость функции sco_sock_connect() модуля net/bluetooth/sco.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-04472
Уязвимость функции iio_sysfs_trigger_remove() модуля drivers/iio/trigger/iio-trig-sysfs.c - драйвера поддержки различных типов встроенных датчиков ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2025-06065
Уязвимость функций nla_alloc_flow_actions() и ovs_nla_free_set_action() модуля net/openvswitch/flow_netlink.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-10269
Уязвимость функции ext4_get_first_dir_block() модуля fs/ext4/namei.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2026-01-20
BDU:2025-10272
Уязвимость функции ieee80211_vif_use_reserved_context() модуля net/mac80211/chan.c реализации стека mac80211 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
BDU:2025-10578
Уязвимость функции ubi_create_volume() модуля drivers/mtd/ubi/vmt.c - драйвера поддержки памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01394
Уязвимость функции nbd_alloc_config() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01498
Уязвимость функции si_parse_power_table() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02207
Уязвимость функции ext4_resize_begin() модуля fs/ext4/resize.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02211
Уязвимость функции hdlcdev_init() модуля drivers/tty/synclink_gt.c - драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02212
Уязвимость функции extcon_dev_register() модуля drivers/extcon/extcon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02213
Уязвимость функции _nfs4_open_and_get_state() модуля fs/nfs/nfs4proc.c поддержки клиентов NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02215
Уязвимость функции rpcrdma_is_bcall() модуля net/sunrpc/xprtrdma/rpc_rdma.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02216
Уязвимость функции trace_event_buffer_lock_reserve() модуля kernel/trace/trace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02217
Уязвимость функции dx_probe() модуля fs/ext4/namei.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02218
Уязвимость функции ext4_convert_inline_data() модуля fs/ext4/inline.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02220
Уязвимость функции icp_opal_init() модуля arch/powerpc/sysdev/xics/icp-opal.c поддержки платформы PowerPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02221
Уязвимость функции nvme_alloc_admin_tags() модуля drivers/nvme/host/pci.c - драйвера поддержки NVME ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02225
Уязвимость функции snd_jack_dev_register() модуля sound/core/jack.c поддержки аудио карт ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02231
Уязвимость функции raid5_add_disk() модуля drivers/md/raid5.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02232
Уязвимость функции ata_host_alloc_pinfo() модуля drivers/ata/libata-core.c - драйвера поддержки SATA/PATA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02253
Уязвимость функции validate_region_size() модуля drivers/md/dm-raid.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02266
Уязвимость функции cx25821_finidev() модуля drivers/media/pci/cx25821/cx25821-core.c драйвера поддержки мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02269
Уязвимость функции dcscb_init() модуля arch/arm/mach-vexpress/dcscb.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02568
Уязвимость функции hfi1_write_iter() модуля drivers/infiniband/hw/hfi1/file_ops.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02569
Уязвимость функции pci_dev_lock() модуля drivers/pci/pci.c драйвера поддержки утройств PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02570
Уязвимость функции md_bitmap_read_sb() модуля drivers/md/md-bitmap.c драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02596
Уязвимость функции r871xu_drv_init() модуля drivers/staging/rtl8712/usb_intf.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02598
Уязвимость функции isp116x_remove() модуля drivers/usb/host/isp116x-hcd.c драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02599
Уязвимость функции sa1100_set_termios() модуля drivers/tty/serial/sa1100.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02600
Уязвимость функции ieee80211_beacons_stop() модуля drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02601
Уязвимость функции oxu_bus_suspend() модуля drivers/usb/host/oxu210hp-hcd.c драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02603
Уязвимость функции mips_cpc_default_phys_base() модуля arch/mips/kernel/mips-cpc.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02604
Уязвимость функции rtl8180_tx() модуля drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c - драйвера поддержки адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02607
Уязвимость функции user_dlm_destroy_lock() модуля fs/ocfs2/dlmfs/userdlm.c поддержки файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02615
Уязвимость функции hi3xxx_smp_prepare_cpus() модуля arch/arm/mach-hisi/platsmp.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02616
Уязвимость функции kszphy_config_reset() модуля drivers/net/phy/micrel.c - драйвера поддержки сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02620
Уязвимость функции virtio_gpu_conn_get_modes() модуля drivers/gpu/drm/virtio/virtgpu_display.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02622
Уязвимость функции libipw_xmit() модуля drivers/net/wireless/intel/ipw2x00/libipw_tx.c - драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02625
Уязвимость функции machine_setup() модуля arch/xtensa/platforms/xtfpga/setup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02626
Уязвимость функции calibrate_ccount() модуля arch/xtensa/kernel/time.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02627
Уязвимость функции l2tp_ip6_sendmsg() модуля net/l2tp/l2tp_ip6.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02629
Уязвимость функции nfcmrvl_play_deferred() модуля drivers/nfc/nfcmrvl/usb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02648
Уязвимость функции icom_probe() модуля drivers/tty/serial/icom.c драйвера поддержки консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02650
Уязвимость функции rtllib_beacons_stop() модуля drivers/staging/rtl8192e/rtllib_softmac.c - поддержки дополнительных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03488
Уязвимость функции clcdfb_of_vram_setup() модуля drivers/video/fbdev/amba-clcd.c драйвера поддержки устройств кадрового буфера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03493
Уязвимость функции tcp_mtup_probe_success() модуля net/ipv4/tcp_input.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03494
Уязвимость функции seg6_hmac_init() модуля net/ipv6/seg6_hmac.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03495
Уязвимость функции xfrm4_protocol_init() модуля net/ipv4/xfrm4_protocol.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03496
Уязвимость функции mdio_bus_init() модуля drivers/net/phy/mdio_bus.c драйвера поддержки сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03671
Уязвимость функции nbd_cleanup() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03672
Уязвимость функции nbd_start_device_ioctl() модуля drivers/block/nbd.c драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03674
Уязвимость функции bpf_int_jit_compile() модуля arch/arm64/net/bpf_jit_comp.c поддержки сети на платформе ARM 64бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03675
Уязвимость функции tcp_rtx_synack() модуля net/ipv4/tcp_output.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03676
Уязвимость функции goldfish_tty_probe() модуля drivers/tty/goldfish.c драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03678
Уязвимость функции ath9k_rx_prepare() модуля drivers/net/wireless/ath/ath9k/htc_drv_txrx.c драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03679
Уязвимость функции f2fs_drop_inmem_page() модуля fs/f2fs/segment.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03692
Уязвимость функции rk3399_dmcfreq_remove() модуля drivers/devfreq/rk3399_dmc.c драйвера поддержки динамического масштабирования напряжения и частоты (DVFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03705
Уязвимость функции gs_can_open() модуля drivers/net/can/usb/gs_usb.c драйвера поддержки сетевых устройств CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03707
Уязвимость функции erspan_fb_xmit() модуля net/ipv4/ip_gre.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03708
Уязвимость функции ext4_mb_normalize_request() модуля fs/ext4/mballoc.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03712
Уязвимость функции goldfish_tty_remove() модуля drivers/tty/goldfish.c драйвера поддержки консоли TTY ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
BDU:2026-03713
Уязвимость функции i40e_diag_test() модуля drivers/net/ethernet/intel/i40e/i40e_ethtool.c драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03810
Уязвимость функции __drm_universal_plane_init() модуля drivers/gpu/drm/drm_plane.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03862
Уязвимость функции dlm_posix_lock() модуля fs/dlm/plock.c поддержки распределенного менеджера блокировок ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03869
Уязвимость функции register_node() модуля drivers/base/node.c драйвера поддержки шинных устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03891
Уязвимость функции tun_detach_all() модуля drivers/net/tun.c драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03899
Уязвимость функции blkcg_iolatency_throttle() модуля block/blk-iolatency.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03999
Уязвимость функции afs_getattr() модуля fs/afs/inode.c файловой системы Andrew (AFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04025
Уязвимость функции mdp5_crtc_setup_pipeline() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04026
Уязвимость функции mdp5_pipe_assign() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04030
Уязвимость функции sdma_clean() модуля drivers/infiniband/hw/hfi1/sdma.c драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04038
Уязвимость функции ipgre_xmit() модуля net/ipv4/ip_gre.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04274
Уязвимость функции qcom_qmp_phy_create() модуля drivers/phy/qualcomm/phy-qcom-qmp.c драйвера поддержки PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04275
Уязвимость функции qcom_qmp_phy_create() модуля drivers/phy/qualcomm/phy-qcom-qmp.c драйвера поддержки PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-14
CVE-2021-47659
In the Linux kernel, the following vulnerability has been resolved: drm/plane: Move range check for format_count earlier While the check for format_count > 64 in __drm_universal_plane_init() shouldn't be hit (it's a WARN_ON), in its current position it will then leak the plane->format_types array and fail to call drm_mode_object_unregister() leaking the modeset identifier. Move it to the start of the function to avoid allocating those resources in the first place.
- https://git.kernel.org/stable/c/1e29d829ad51d1472dd035487953a6724b56fc33
- https://git.kernel.org/stable/c/4ab7e453a3ee88c274cf97bee9487ab92a66d313
- https://git.kernel.org/stable/c/4b674dd69701c2e22e8e7770c1706a69f3b17269
- https://git.kernel.org/stable/c/787163d19bc3cdc6ca4b96223f62208534d1cf6b
- https://git.kernel.org/stable/c/978e3d023256bfaf34a0033d40c94e8a8e70cf3c
- https://git.kernel.org/stable/c/ad6dd7a2bac86118985c7b3426e175b9d3c1ec4f
- https://git.kernel.org/stable/c/b5cd108143513e4498027b96ec4710702d186f11
Modified: 2024-11-21
CVE-2022-1184
A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel’s filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service.
- https://access.redhat.com/security/cve/CVE-2022-1184
- https://bugzilla.redhat.com/show_bug.cgi?id=2070205
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://ubuntu.com/security/CVE-2022-1184
- https://www.debian.org/security/2022/dsa-5257
- https://access.redhat.com/security/cve/CVE-2022-1184
- https://bugzilla.redhat.com/show_bug.cgi?id=2070205
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://ubuntu.com/security/CVE-2022-1184
- https://www.debian.org/security/2022/dsa-5257
Modified: 2024-11-21
CVE-2022-26365
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
Modified: 2024-11-21
CVE-2022-32250
net/netfilter/nf_tables_api.c in the Linux kernel through 5.18.1 allows a local user (able to create user/net namespaces) to escalate privileges to root because an incorrect NFT_STATEFUL_EXPR check leads to a use-after-free.
- http://www.openwall.com/lists/oss-security/2022/06/03/1
- http://www.openwall.com/lists/oss-security/2022/06/04/1
- http://www.openwall.com/lists/oss-security/2022/06/20/1
- http://www.openwall.com/lists/oss-security/2022/07/03/5
- http://www.openwall.com/lists/oss-security/2022/07/03/6
- http://www.openwall.com/lists/oss-security/2022/08/25/1
- http://www.openwall.com/lists/oss-security/2022/09/02/9
- https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
- https://bugzilla.redhat.com/show_bug.cgi?id=2092427
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd
- https://github.com/theori-io/CVE-2022-32250-exploit
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/
- https://security.netapp.com/advisory/ntap-20220715-0005/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://www.openwall.com/lists/oss-security/2022/05/31/1
- http://www.openwall.com/lists/oss-security/2022/06/03/1
- http://www.openwall.com/lists/oss-security/2022/06/04/1
- http://www.openwall.com/lists/oss-security/2022/06/20/1
- http://www.openwall.com/lists/oss-security/2022/07/03/5
- http://www.openwall.com/lists/oss-security/2022/07/03/6
- http://www.openwall.com/lists/oss-security/2022/08/25/1
- http://www.openwall.com/lists/oss-security/2022/09/02/9
- https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/
- https://bugzilla.redhat.com/show_bug.cgi?id=2092427
- https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd
- https://github.com/theori-io/CVE-2022-32250-exploit
- https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/
- https://security.netapp.com/advisory/ntap-20220715-0005/
- https://www.debian.org/security/2022/dsa-5161
- https://www.debian.org/security/2022/dsa-5173
- https://www.openwall.com/lists/oss-security/2022/05/31/1
Modified: 2024-11-21
CVE-2022-33740
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
Modified: 2024-11-21
CVE-2022-33741
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
Modified: 2024-11-21
CVE-2022-33742
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742).
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
- http://www.openwall.com/lists/oss-security/2022/07/05/6
- http://xenbits.xen.org/xsa/advisory-403.html
- https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/
- https://www.debian.org/security/2022/dsa-5191
- https://xenbits.xenproject.org/xsa/advisory-403.txt
Modified: 2024-12-31
CVE-2022-48710
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix a possible null pointer dereference In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. The failure status of drm_cvt_mode() on the other path is checked too.
- https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17
- https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f
- https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60
- https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
- https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29
- https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f
- https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9
- https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479
- https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab
- https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17
- https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f
- https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60
- https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9
- https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29
- https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f
- https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9
- https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479
- https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab
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-10-01
CVE-2022-49295
In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-)
- https://git.kernel.org/stable/c/013a79f1b5c89290e2e97f1ebf14b14e0cf5fe5c
- https://git.kernel.org/stable/c/06c4da89c24e7023ea448cadf8e9daf06a0aae6e
- https://git.kernel.org/stable/c/1be608e1ee1f222464b2856bda9b85ab5184a33e
- https://git.kernel.org/stable/c/3d5da1ffba3388c2ae2e6c598855a4d887d3bf79
- https://git.kernel.org/stable/c/6f505bbb8063fd3a238a4239d2d8c165e5279f6f
- https://git.kernel.org/stable/c/8a1435c862ea09b06be7acda325128dc08458e25
- https://git.kernel.org/stable/c/c0868f6e728c3c28bef0e8bee89d2daf86a8bbca
- https://git.kernel.org/stable/c/cbeafa7a79d08ecdb55f8f1d41a11323d0f709db
Modified: 2025-10-21
CVE-2022-49297
In the Linux kernel, the following vulnerability has been resolved:
nbd: fix io hung while disconnecting device
In our tests, "qemu-nbd" triggers a io hung:
INFO: task qemu-nbd:11445 blocked for more than 368 seconds.
Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:qemu-nbd state:D stack: 0 pid:11445 ppid: 1 flags:0x00000000
Call Trace:
- https://git.kernel.org/stable/c/09dadb5985023e27d4740ebd17e6fea4640110e5
- https://git.kernel.org/stable/c/141318e62db87105b0103fccc59c9c5940da248d
- https://git.kernel.org/stable/c/54b06dc2a206b4d67349bb56b92d4bd32700b7b1
- https://git.kernel.org/stable/c/62d227f67a8c25d5e16f40e5290607f9306d2188
- https://git.kernel.org/stable/c/67e403136a0e1a55fef6a05f103a3979a39ad3fd
- https://git.kernel.org/stable/c/69893d6d7f5c10d8306c1b5fc64b71efc91aa6cd
- https://git.kernel.org/stable/c/c4ba982bd5084fa659ef518aaf159e4dab02ecda
- https://git.kernel.org/stable/c/f72df77600a43e59b3189e53b47f8685739867d3
Modified: 2025-10-01
CVE-2022-49298
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in r871xu_drv_init() When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized. BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [inline] hub_port_connect_change drivers/usb/core/hub.c:5502 [inline] port_event drivers/usb/core/hub.c:5660 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 Local variable mac created at: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
- https://git.kernel.org/stable/c/0458e5428e5e959d201a40ffe71d762a79ecedc4
- https://git.kernel.org/stable/c/0b7371a22489cbb2e8e826ca03fb5ce92afb04fe
- https://git.kernel.org/stable/c/277faa442fe0c59f418ac53f47a78e1266addd65
- https://git.kernel.org/stable/c/52a0d88c328098b4e9fb8f2f3877fec0eff4104b
- https://git.kernel.org/stable/c/70df04433fd351ba72bc635bd0b5fe443d9ac964
- https://git.kernel.org/stable/c/76a964ad0ea8f2b10abd69a7532e174a28258283
- https://git.kernel.org/stable/c/a6535d00a9d54ce1c2a8d86a85001ffb6844f9b2
- https://git.kernel.org/stable/c/f36e754a1f0bafb9feeea63463de78080acb6de0
- https://git.kernel.org/stable/c/ff727ab0b7d7a56b5ef281f12abd00c4b85894e9
Modified: 2025-10-01
CVE-2022-49300
In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between nbd_alloc_config() and module removal When nbd module is being removing, nbd_alloc_config() may be called concurrently by nbd_genl_connect(), although try_module_get() will return false, but nbd_alloc_config() doesn't handle it. The race may lead to the leak of nbd_config and its related resources (e.g, recv_workq) and oops in nbd_read_stat() due to the unload of nbd module as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Call Trace: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Fixing it by checking the return value of try_module_get() in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV), assign nbd->config only when nbd_alloc_config() succeeds to ensure the value of nbd->config is binary (valid or NULL). Also adding a debug message to check the reference counter of nbd_config during module removal.
- https://git.kernel.org/stable/c/122e4adaff2439f1cc18cc7e931980fa7560df5c
- https://git.kernel.org/stable/c/165cf2e0019fa6cedc75b456490c41494c34abb4
- https://git.kernel.org/stable/c/2573f2375b64280be977431701ed5d33b75b9ad0
- https://git.kernel.org/stable/c/2888fa41985f93ed0a6837cfbb06bcbfd7fa2314
- https://git.kernel.org/stable/c/71c142f910da44421213ade601bcbd23ceae19fa
- https://git.kernel.org/stable/c/8a7da4ced236ce6637fe70f14ca18e718d4bf9e9
- https://git.kernel.org/stable/c/c55b2b983b0fa012942c3eb16384b2b722caa810
- https://git.kernel.org/stable/c/d09525720dd5201756f698bee1076de9aefd4602
Modified: 2025-10-01
CVE-2022-49302
In the Linux kernel, the following vulnerability has been resolved: USB: host: isp116x: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e
- https://git.kernel.org/stable/c/3592cfd8b848bf0c4d7740d78a87a7b8f6e1fa9a
- https://git.kernel.org/stable/c/3825db88d8c704e7992b685618a03f82bffcf2ef
- https://git.kernel.org/stable/c/7bffda1560a6f255fdf504e059fbbdb5d46b9e44
- https://git.kernel.org/stable/c/804de302ada3544699c5f48c5314b249af76faa3
- https://git.kernel.org/stable/c/82a101f14943f479fd190b1e5b40d91c77e2ac1b
- https://git.kernel.org/stable/c/aca0cab0e9ed33b6371aafb519a6c38f2850ffc3
- https://git.kernel.org/stable/c/c91a74b1f0f2d2d7e728742ae55e3ffe9ba7853d
- https://git.kernel.org/stable/c/ee105039d3653444de4d3ede642383c92855dc1e
Modified: 2025-10-01
CVE-2022-49304
In the Linux kernel, the following vulnerability has been resolved: drivers: tty: serial: Fix deadlock in sa1100_set_termios() There is a deadlock in sa1100_set_termios(), which is shown below: (Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->port.lock in position (2) of thread 2. As a result, sa1100_set_termios() will block forever. This patch moves del_timer_sync() before spin_lock_irqsave() in order to prevent the deadlock.
- https://git.kernel.org/stable/c/0976808d0d171ec837d4bd3e9f4ad4a00ab703b8
- https://git.kernel.org/stable/c/09a5958a2452ad22d0cb638711ef34ea1863a829
- https://git.kernel.org/stable/c/2cbfc38df580bff5b2fe19f21c1a7520efcc4b3b
- https://git.kernel.org/stable/c/34d91e555e5582cffdbcbb75517bc9217866823e
- https://git.kernel.org/stable/c/553213432ef0c295becdc08c0207d2094468f673
- https://git.kernel.org/stable/c/62b2caef400c1738b6d22f636c628d9f85cd4c4c
- https://git.kernel.org/stable/c/6e2273eefab54a521d9c59efb6e1114e742bdf41
- https://git.kernel.org/stable/c/85e20f8bd31a46d8c60103d0274a8ebe8f47f2b2
- https://git.kernel.org/stable/c/920f0ae7a129ffee98a106e3bbdfd61a2a59e939
Modified: 2025-10-01
CVE-2022-49305
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/042915c1bfedd684c1d98a841794ee203200571a
- https://git.kernel.org/stable/c/1fbe033c52480f7954c057510040fa6286c4ea25
- https://git.kernel.org/stable/c/66f769762f65d957f688f3258755c6ec410bf710
- https://git.kernel.org/stable/c/806c7b53414934ba2a39449b31fd1a038e500273
- https://git.kernel.org/stable/c/b34cb54923a6e5ddefbaf358c85c922c6ab456e2
- https://git.kernel.org/stable/c/b465bb2ebf666116c1ac745cb80c65154dc0d27e
- https://git.kernel.org/stable/c/ffc9cab7243f8151be37966301307bfd3cda2db3
Modified: 2025-10-01
CVE-2022-49307
In the Linux kernel, the following vulnerability has been resolved:
tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()
When the driver fails at alloc_hdlcdev(), and then we remove the driver
module, we will get the following splat:
[ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI
[ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]
[ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0
[ 25.077709] Call Trace:
[ 25.077924]
- https://git.kernel.org/stable/c/078212ad15dbd88840c82c97f12c93d83703c8fd
- https://git.kernel.org/stable/c/1ceb4ca9543a8a788febf6bc8dad2e605e172d5e
- https://git.kernel.org/stable/c/50c341f9a2adc4c32a8ad5a39eb99d9c4a419e0d
- https://git.kernel.org/stable/c/689ca31c542687709ba21ec2195c1fbce34fd029
- https://git.kernel.org/stable/c/8a95696bdc0e13f8980f05b54a3b9081963d1256
- https://git.kernel.org/stable/c/ba08cbc5b53e151d0acf1930fb526fc65b7f3e65
- https://git.kernel.org/stable/c/d68d5e68b7f64de7170f8e04dd9b995c36b2c71c
- https://git.kernel.org/stable/c/ddd67751ab86c6a65f95c35293c42f85a42ac05d
- https://git.kernel.org/stable/c/f6e07eb7ebec53ffe81fc2489589320fbe4a6b75
Modified: 2025-10-21
CVE-2022-49308
In the Linux kernel, the following vulnerability has been resolved:
extcon: Modify extcon device to be created after driver data is set
Currently, someone can invoke the sysfs such as state_show()
intermittently before dev_set_drvdata() is done.
And it can be a cause of kernel Oops because of edev is Null at that time.
So modified the driver registration to after setting drviver data.
- Oops's backtrace.
Backtrace:
[
- https://git.kernel.org/stable/c/033ec4e7e59ae5e1ef1e8c10bc6552926044ed1c
- https://git.kernel.org/stable/c/35ff1ac55d301efb3f467cf5426faaeb3452994b
- https://git.kernel.org/stable/c/368e68ad6da4317fc4170e8d92b51c13d1bfe7a7
- https://git.kernel.org/stable/c/5dcc2afe716d69f5112ce035cb14f007461ff189
- https://git.kernel.org/stable/c/6e721f3ad0535b24f19a62420f4da95212cf069c
- https://git.kernel.org/stable/c/abf3b222614f49f98e606fccdd269161c0d70204
- https://git.kernel.org/stable/c/cb81ea998c461868d1168411a867d8ffee12f23f
- https://git.kernel.org/stable/c/d472c78cc82999d07bd09193a6718016ce9cd386
Modified: 2025-10-01
CVE-2022-49313
In the Linux kernel, the following vulnerability has been resolved: drivers: usb: host: Fix deadlock in oxu_bus_suspend() There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/2dcec0bc142be2096af71a5703d63237127db204
- https://git.kernel.org/stable/c/4187b291a76664a3c03d3f0d9bfadc8322881868
- https://git.kernel.org/stable/c/4d378f2ae58138d4c55684e1d274e7dd94aa6524
- https://git.kernel.org/stable/c/9b58d255f27b0ed6a2e43208960864d67579db58
- https://git.kernel.org/stable/c/a3d380188bde8900c3f604e82b56572896499124
- https://git.kernel.org/stable/c/b97aae8b43b718314012e8170b7e03dbfd2e7677
- https://git.kernel.org/stable/c/d888753872190abd18f68a7d77b9c7c367f0a7ab
- https://git.kernel.org/stable/c/f8242044c91cafbba9e320b0fb31abf2429a3221
- https://git.kernel.org/stable/c/ffe9440d698274c6462d2e304562c6ddfc8c84df
Modified: 2025-10-01
CVE-2022-49314
In the Linux kernel, the following vulnerability has been resolved: tty: Fix a possible resource leak in icom_probe When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated.
- https://git.kernel.org/stable/c/23e155b51d403c0ccedc60c0d6c3c452afed07fe
- https://git.kernel.org/stable/c/5f9b2e4ca88cab1a96b86ecd45544e488ca43faf
- https://git.kernel.org/stable/c/8c014373f178a4f13a08e045ef63bdb23f62e892
- https://git.kernel.org/stable/c/9a8305f357a8d03698fc7bc855ff9c6865d5486b
- https://git.kernel.org/stable/c/a2df0b4d080cc770b4da7bff487048c803dfd07e
- https://git.kernel.org/stable/c/cb7147afd328c07edeeee287710d8d96ac0459f5
- https://git.kernel.org/stable/c/d703d912a985c1c5b50dd38c3181fc3540fa77cb
- https://git.kernel.org/stable/c/ee157a79e7c82b01ae4c25de0ac75899801f322c
- https://git.kernel.org/stable/c/f4c836d90da1ece88905d62ce2ce39a962f25d1a
Modified: 2025-10-01
CVE-2022-49315
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop() There is a deadlock in rtllib_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock.
- https://git.kernel.org/stable/c/08bacf871c019163ccd1389d0bc957a43324967a
- https://git.kernel.org/stable/c/0f69d7d5e918aa43423d86bd17ddb11b1b5e8ada
- https://git.kernel.org/stable/c/381045dc64d23a2229c47c5524c06bfc33d34446
- https://git.kernel.org/stable/c/4681129fda9e8555392eaaadb239ec6a6e2b3e12
- https://git.kernel.org/stable/c/46c861009bf437a18417df24cea0d181741b7d72
- https://git.kernel.org/stable/c/64b05fa212c7e4d057676e8b7e7120c6eb2f615b
- https://git.kernel.org/stable/c/9b6bdbd9337de3917945847bde262a34a87a6303
- https://git.kernel.org/stable/c/fef451f0fbbe85dbd2962b18379d02e2965610db
- https://git.kernel.org/stable/c/ffd4c4d5293e4985092ea45ba21cad9326e2e434
Modified: 2025-10-01
CVE-2022-49316
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Don't hold the layoutget locks across multiple RPC calls When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock.
- https://git.kernel.org/stable/c/08d7a26d115cc7892668baa9750f64bd8baca29b
- https://git.kernel.org/stable/c/0ee5b9644f06b4d3cdcd9544f43f63312e425a4c
- https://git.kernel.org/stable/c/6949493884fe88500de4af182588e071cf1544ee
- https://git.kernel.org/stable/c/6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010
- https://git.kernel.org/stable/c/a2b3be930e79cc5d9d829f158e31172b2043f0cd
- https://git.kernel.org/stable/c/d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e
- https://git.kernel.org/stable/c/ea759ae0a9ae5acee677d722129710ac89cc59c1
Modified: 2025-10-01
CVE-2022-49321
In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ? create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0 [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724] ret_from_fork+0x35/0x40 ...
- https://git.kernel.org/stable/c/11270e7ca268e8d61b5d9e5c3a54bd1550642c9c
- https://git.kernel.org/stable/c/8dbae5affbdbf524b48000f9d357925bb001e5f4
- https://git.kernel.org/stable/c/8e3943c50764dc7c5f25911970c3ff062ec1f18c
- https://git.kernel.org/stable/c/90c4f73104016748533a5707ecd15930fbeff402
- https://git.kernel.org/stable/c/91784f3d77b73885e1b2e6b59d3cbf0de0a1126a
- https://git.kernel.org/stable/c/998d35a2aff4b81a1c784f3aa45cd3afff6814c1
- https://git.kernel.org/stable/c/a3fc8051ee061e31db13e2fe011e8e0b71a7f815
- https://git.kernel.org/stable/c/da99331fa62131a38a0947a8204c5208de7b0454
Modified: 2025-10-01
CVE-2022-49322
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix sleeping function called from invalid context on RT kernel
When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the
cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the
atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,
these locks are replaced with sleepable rt-spinlock, so the stack calltrace will
be triggered.
Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start
tp_printk=1" enabled.
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
Preemption disabled at:
[
- https://git.kernel.org/stable/c/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd
- https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762
- https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4
- https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b
- https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0
- https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59
- https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec
- https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1
Modified: 2025-10-01
CVE-2022-49324
In the Linux kernel, the following vulnerability has been resolved: mips: cpc: Fix refcount leak in mips_cpc_default_phys_base Add the missing of_node_put() to release the refcount incremented by of_find_compatible_node().
- https://git.kernel.org/stable/c/1699ec1bfb59304a788901474f6bb003f7831b61
- https://git.kernel.org/stable/c/4107fa700f314592850e2c64608f6ede4c077476
- https://git.kernel.org/stable/c/8f843cdfc202caaa5d67db3395d893e56362e43a
- https://git.kernel.org/stable/c/961ee8a6eeef4632a215d995d837b204f8c7c2d4
- https://git.kernel.org/stable/c/aae6b4bb63c694bc91714412718f15468407fe51
- https://git.kernel.org/stable/c/bed702566dcdb6ebe300bc0c62bf3600cf4d5874
- https://git.kernel.org/stable/c/c667b3872a4c435a3f29d4e15971cd8c378b0043
- https://git.kernel.org/stable/c/cc0aed22d33ced9e266c50bdf1cbe668c5acfdf8
Modified: 2025-10-01
CVE-2022-49326
In the Linux kernel, the following vulnerability has been resolved: rtl818x: Prevent using not initialized queues Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized.
- https://git.kernel.org/stable/c/6ad81ad0cf5744738ce94c8e64051ddd80a1734c
- https://git.kernel.org/stable/c/746285cf81dc19502ab238249d75f5990bd2d231
- https://git.kernel.org/stable/c/769ec2a824deae2f1268dfda14999a4d14d0d0c5
- https://git.kernel.org/stable/c/98e55b0b876bde3353f4e074883d66ecb55c65a3
- https://git.kernel.org/stable/c/9ad1981fc4de3afb7db3e8eb5a6a52d4c7d0d577
- https://git.kernel.org/stable/c/9d5e96cc1f1720019ce27b127a31695148d38bb0
- https://git.kernel.org/stable/c/b5dca2cd3f0239512da808598b4e70557eb4c2a1
- https://git.kernel.org/stable/c/b8ce58ab80faaea015c206382041ff3bcf5495ff
- https://git.kernel.org/stable/c/d7e30dfc166d33470bba31a42f9bbc346e5409d5
Modified: 2025-09-22
CVE-2022-49330
In the Linux kernel, the following vulnerability has been resolved:
tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd
syzbot got a new report [1] finally pointing to a very old bug,
added in initial support for MTU probing.
tcp_mtu_probe() has checks about starting an MTU probe if
tcp_snd_cwnd(tp) >= 11.
But nothing prevents tcp_snd_cwnd(tp) to be reduced later
and before the MTU probe succeeds.
This bug would lead to potential zero-divides.
Debugging added in commit 40570375356c ("tcp: add accessors
to read/set tp->snd_cwnd") has paid off :)
While we are at it, address potential overflows in this code.
[1]
WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Modules linked in:
CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]
RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712
Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff
RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287
RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000
RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f
RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520
R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50
R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000
FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/11825765291a93d8e7f44230da67b9f607c777bf
- https://git.kernel.org/stable/c/29e13f6b38f0816af2012e0725507754e8f4569c
- https://git.kernel.org/stable/c/38ca71a24cd4845021eed35fd2594d89dba9a5a8
- https://git.kernel.org/stable/c/42726877453afdbe1508a8a96884ea907741d9a7
- https://git.kernel.org/stable/c/602b338e3c3cd7f935f3f5011882961d074e5ac1
- https://git.kernel.org/stable/c/90385f2b65d0cd2b3b1ac8909f0cc6dd31062cfc
- https://git.kernel.org/stable/c/9ba2b4ac35935f05ac98cff722f36ba07d62270e
- https://git.kernel.org/stable/c/aa7f333efd1138a68517a6a6a69ae540dd59d800
- https://git.kernel.org/stable/c/f2845e1504a3bc4f3381394f057e8b63cb5f3f7a
Modified: 2025-10-01
CVE-2022-49331
In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths.
- https://git.kernel.org/stable/c/3eca2c42daa4659965db6817479027cbc6df7899
- https://git.kernel.org/stable/c/54423649bc0ed464b75807a7cf2857a5871f738f
- https://git.kernel.org/stable/c/55904086041ba4ee4070187b36590f8f8d6df4cd
- https://git.kernel.org/stable/c/593773088d615a46a42c97e01a0550d192bb7f74
- https://git.kernel.org/stable/c/6fce324b530dd74750ad870699e33eeed1029ded
- https://git.kernel.org/stable/c/996419e0594abb311fb958553809f24f38e7abbe
- https://git.kernel.org/stable/c/d221ce54ce331c1a23be71eebf57f6a088632383
- https://git.kernel.org/stable/c/db836b97464d44340b568e041fd24602858713f7
- https://git.kernel.org/stable/c/f444ecd3f57f4ba5090fe8b6756933e37de4226e
Modified: 2025-10-01
CVE-2022-49335
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018
- https://git.kernel.org/stable/c/15c3bcc9b5349d40207e5f8d4d799b8b4b7d13b8
- https://git.kernel.org/stable/c/20b947e5a3c74c5084d661c097517a554989d462
- https://git.kernel.org/stable/c/31ab27b14daaa75541a415c6794d6f3567fea44a
- https://git.kernel.org/stable/c/70276460e914d560e96bfc208695a872fe9469c9
- https://git.kernel.org/stable/c/7086a23890d255bb5761604e39174b20d06231a4
- https://git.kernel.org/stable/c/8189f44270db1be78169e11eec51a3eeb980bc63
- https://git.kernel.org/stable/c/aa25acbe96692e4bf8482311c293f72d8c6034c0
- https://git.kernel.org/stable/c/be585921f29df5422a39c952d188b418ad48ffab
- https://git.kernel.org/stable/c/c12984cdb077b9042d2dc20ca18cb16a87bcc774
Modified: 2025-09-22
CVE-2022-49337
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_lock failed, it didn't clean up the flags it set
before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of
lock is still in used, next time when unlink invokes this function, it
will return succeed, and then unlink will remove inode and dentry if lock
is not in used(file closed), but the dlm lock is still linked in dlm lock
resource, then when bast come in, it will trigger a panic due to
user-after-free. See the following panic call trace. To fix this,
USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should
be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink
fail.
For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN,
USER_LOCK_BUSY is also required to be cleared. Even though spin lock is
released in between, but USER_LOCK_IN_TEARDOWN is still set, for
USER_LOCK_BUSY, if before every place that waits on this flag,
USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow
waits on the busy flag set by user_dlm_destroy_lock(), then we can
simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix
user_dlm_cluster_lock() which is the only function not following this.
[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink
004fb0000060000b5a90b8c847b72e1, error -16 from destroy
[ 989.757536] ------------[ cut here ]------------
[ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!
[ 989.757876] invalid opcode: 0000 [#1] SMP
[ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)
ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc
xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5
auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs
ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc
fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc
rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad
rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE)
mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad
ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support
pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si
ipmi_msghandler
[ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp
pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel
be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio
libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi
dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
ksplice_2zhuk2jr_ib_ipoib_old]
[ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE
4.1.12-124.57.1.el6uek.x86_64 #2
[ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021
[ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:
ffff88017f7c8000
[ 989.762848] RIP: e030:[
- https://git.kernel.org/stable/c/02480e2e82ae0e5588374bbbcf4fa6e4959fa174
- https://git.kernel.org/stable/c/1434cd71ad9f3a6beda3036972983b6c4869207c
- https://git.kernel.org/stable/c/2c5e26a626fe46675bceba853e12aaf13c712e10
- https://git.kernel.org/stable/c/337e36550788dbe03254f0593a231c1c4873b20d
- https://git.kernel.org/stable/c/733a35c00ef363a1c774d7ea486e0735b7c13a15
- https://git.kernel.org/stable/c/82bf8e7271fade40184177cb406203addc34c4a0
- https://git.kernel.org/stable/c/863e0d81b6683c4cbc588ad831f560c90e494bef
- https://git.kernel.org/stable/c/9c96238fac045b289993d7bc5aae7b2d72b25c76
- https://git.kernel.org/stable/c/efb54ec548829e1d3605f0434526f86e345b1b28
Modified: 2025-09-22
CVE-2022-49339
In the Linux kernel, the following vulnerability has been resolved: net: ipv6: unexport __init-annotated seg6_hmac_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the caller (net/ipv6/seg6.c) and the callee (net/ipv6/seg6_hmac.c) belong to the same module. It seems an internal function call in ipv6.ko.
- https://git.kernel.org/stable/c/1084716f76c8045eadf92a9d9a62641f3c8d8c90
- https://git.kernel.org/stable/c/317260b3eb6384a05a8af212308fa50f3b2e8290
- https://git.kernel.org/stable/c/3e6de5037148c5a93a436b1e8d2edad3dac11755
- https://git.kernel.org/stable/c/5801f064e35181c71857a80ff18af4dbec3c5f5c
- https://git.kernel.org/stable/c/5d9c1b081ad28c852a97e10dd75412546497694a
- https://git.kernel.org/stable/c/64aef8efe96c1616142c4476a05731306fc4494e
- https://git.kernel.org/stable/c/9ba4416b831eeb4d185e88e73488d1d21288e63a
- https://git.kernel.org/stable/c/ab8b2c2de273ec1d698a18e399896a6febb5cda0
Modified: 2025-10-21
CVE-2022-49340
In the Linux kernel, the following vulnerability has been resolved: ip_gre: test csum_start instead of transport header GRE with TUNNEL_CSUM will apply local checksum offload on CHECKSUM_PARTIAL packets. ipgre_xmit must validate csum_start after an optional skb_pull, else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; This had false positives when skb_checksum_start is undefined: when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement was straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; But was eventually revised more thoroughly: - restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull. - test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath. Turns out skbs can arrive in this branch without the transport header set, e.g., through BPF redirection. Revise the check back to check csum_start directly, and only if CHECKSUM_PARTIAL. Do leave the check in the updated location. Check field regardless of whether TUNNEL_CSUM is configured.
- https://git.kernel.org/stable/c/0c92d813c7c9ca2212ecd879232e7d87362fce98
- https://git.kernel.org/stable/c/0ffa268724656633af5f37a38c212326d98ebe8c
- https://git.kernel.org/stable/c/3d08bc3a5d9b2106f5c8bcf1adb73147824aa006
- https://git.kernel.org/stable/c/7596bd7920985f7fc8579a92e48bc53ce4475b21
- https://git.kernel.org/stable/c/8d21e9963bec1aad2280cdd034c8993033ef2948
- https://git.kernel.org/stable/c/e6b6f98fc7605c06c0a3baa70f62c534d7b4ce58
- https://git.kernel.org/stable/c/fbeb8dfa8b87ef259eef0c89e39b53962a3cf604
Modified: 2025-10-21
CVE-2022-49341
In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Clear prog->jited_len along prog->jited syzbot reported an illegal copy_to_user() attempt from bpf_prog_get_info_by_fd() [1] There was no repro yet on this bug, but I think that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns") is exposing a prior bug in bpf arm64. bpf_prog_get_info_by_fd() looks at prog->jited_len to determine if the JIT image can be copied out to user space. My theory is that syzbot managed to get a prog where prog->jited_len has been set to 43, while prog->bpf_func has ben cleared. It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering this particular warning. I thought find_vma_area(NULL) would not find a vm_struct. As we do not hold vmap_area_lock spinlock, it might be possible that the found vm_struct was garbage. [1] usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)! kernel BUG at mm/usercopy.c:101! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0 Hardware name: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865 x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830 x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064 Call trace: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [inline] __check_object_size mm/usercopy.c:252 [inline] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [inline] check_copy_size include/linux/thread_info.h:235 [inline] copy_to_user include/linux/uaccess.h:159 [inline] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [inline] __se_sys_bpf kernel/bpf/syscall.c:5019 [inline] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)
- https://git.kernel.org/stable/c/0cf7aaff290cdc4d7cee683d4a18138b0dacac48
- https://git.kernel.org/stable/c/10f3b29c65bb2fe0d47c2945cd0b4087be1c5218
- https://git.kernel.org/stable/c/3f4d5e727aeaa610688d46c9f101f78b7f712583
- https://git.kernel.org/stable/c/41f7c4f85d402043687e863627a1a84fa867c62d
- https://git.kernel.org/stable/c/5c25a3040bc0486c41a7b63a1fb0de7cdb846ad7
- https://git.kernel.org/stable/c/aaf61a312af63e1cfe2264c4c5b8cd4ea3626025
- https://git.kernel.org/stable/c/e412b3d178ea4bf746f6b8ee086761613704c6be
Modified: 2025-10-21
CVE-2022-49343
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid cycles in directory h-tree A maliciously corrupted filesystem can contain cycles in the h-tree stored inside a directory. That can easily lead to the kernel corrupting tree nodes that were already verified under its hands while doing a node split and consequently accessing unallocated memory. Fix the problem by verifying traversed block numbers are unique.
- https://git.kernel.org/stable/c/24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3
- https://git.kernel.org/stable/c/3a3ce941645407cd0b0b7f01ad9e2ea3770f46cc
- https://git.kernel.org/stable/c/3ba733f879c2a88910744647e41edeefbc0d92b2
- https://git.kernel.org/stable/c/6084240bfc44bf265ab6ae7d96980469b05be0f1
- https://git.kernel.org/stable/c/b3ad9ff6f06c1dc6abf7437691c88ca3d6da3ac0
- https://git.kernel.org/stable/c/d5a16a6df2c16eaf4de04948553ef0089dee463f
- https://git.kernel.org/stable/c/e157c8f87e8fac112d6c955e69a60cdb9bc80a60
- https://git.kernel.org/stable/c/ff4cafa51762da3824881a9000ca421d4b78b138
Modified: 2025-10-01
CVE-2022-49344
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race.
- https://git.kernel.org/stable/c/556720013c36c193d9cbfb06e7b33e51f0c39fbf
- https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432
- https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2
- https://git.kernel.org/stable/c/8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6
- https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca
- https://git.kernel.org/stable/c/c61848500a3fd6867dfa4834b8c7f97133eceb9f
- https://git.kernel.org/stable/c/c926ae58f24f7bd55aa2ea4add9f952032507913
Modified: 2025-09-22
CVE-2022-49345
In the Linux kernel, the following vulnerability has been resolved: net: xfrm: unexport __init-annotated xfrm4_protocol_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, net/ipv4/xfrm4_policy.c is never compiled as modular. (CONFIG_XFRM is boolean)
- https://git.kernel.org/stable/c/2b253fbc9f7b5db18d716436bdcf8ecef09fd63d
- https://git.kernel.org/stable/c/31f3c6a4dcd3260a386e62cef2d5b36e902600a1
- https://git.kernel.org/stable/c/4a388f08d8784af48f352193d2b72aaf167a57a1
- https://git.kernel.org/stable/c/85a055c03691e51499123194a14a0c249cf33227
- https://git.kernel.org/stable/c/be3884d5cd04ccd58294b83a02d70b7c5fca19d3
- https://git.kernel.org/stable/c/c58d82a1264813e69119c13e9804e2e60b664ad5
- https://git.kernel.org/stable/c/e04d59cfe0c0129df7aba7ef7bb17b96be2a64f2
- https://git.kernel.org/stable/c/e53cd3814504b2cadaba4d5a8a07eeea9ddacd03
- https://git.kernel.org/stable/c/ef6d2354de238b065d8799c80da4be9a6af18e39
Modified: 2025-09-22
CVE-2022-49347
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug_on in ext4_writepages
we got issue as follows:
EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls
------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2708!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155
RIP: 0010:ext4_writepages+0x1977/0x1c10
RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88811c098000
RDX: 0000000000000000 RSI: ffff88811c098000 RDI: 0000000000000002
RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: 0000000000000000
R10: 0000000000000007 R11: ffffed10250281ea R12: 0000000000000001
R13: 00000000000000a4 R14: ffff88811d3e7bb8 R15: ffff888128141028
FS: 00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020007200 CR3: 000000011c2a4000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/013f12bdedb96816aaa27ee04349f4433d361f52
- https://git.kernel.org/stable/c/18a759f7f99f0b65a08ff5b7e745fc405a42bde4
- https://git.kernel.org/stable/c/19918ec7717d87d5ab825884a46b26b21375d7ce
- https://git.kernel.org/stable/c/1b061af037646c9cdb0afd8a8d2f1e1c06285866
- https://git.kernel.org/stable/c/1cde35417edc0370fb0179a4e38b78a15350a8d0
- https://git.kernel.org/stable/c/73fd5b19285197078ee8a2e651d75d5b094a4de9
- https://git.kernel.org/stable/c/b2b78f5bf2d453dda3903955efee059260787a42
- https://git.kernel.org/stable/c/de1732b5c1693ad489c5d254f124f67cb775f37d
- https://git.kernel.org/stable/c/ef09ed5d37b84d18562b30cf7253e57062d0db05
Modified: 2025-03-25
CVE-2022-49349
In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ]
- https://git.kernel.org/stable/c/0be698ecbe4471fcad80e81ec6a05001421041b3
- https://git.kernel.org/stable/c/0ff38b99fa075ddd246487a28cb9af049f4ceef1
- https://git.kernel.org/stable/c/10801095224de0d0ab06ae60698680c1f883a3ae
- https://git.kernel.org/stable/c/1a3a15bf6f9963d755270cbdb282863b84839195
- https://git.kernel.org/stable/c/364380c00912bed9b5d99eb485018360b0ecf64f
- https://git.kernel.org/stable/c/4a2bea60cf7ff957b3eda0b17750d483876a02fa
- https://git.kernel.org/stable/c/97f802a652a749422dede32071d29a53cf4bd034
- https://git.kernel.org/stable/c/dd887f83ea54aea5b780a84527e23ab95f777fed
- https://git.kernel.org/stable/c/eaecf7ebfd5dd09038a80b14be46b844f54cfc5c
Modified: 2025-09-22
CVE-2022-49350
In the Linux kernel, the following vulnerability has been resolved: net: mdio: unexport __init-annotated mdio_bus_init() EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it has been broken for a decade. Recently, I fixed modpost so it started to warn it again, then this showed up in linux-next builds. There are two ways to fix it: - Remove __init - Remove EXPORT_SYMBOL I chose the latter for this case because the only in-tree call-site, drivers/net/phy/phy_device.c is never compiled as modular. (CONFIG_PHYLIB is boolean)
- https://git.kernel.org/stable/c/35b42dce619701f1300fb8498dae82c9bb1f0263
- https://git.kernel.org/stable/c/5534bcd7c40299862237c4a8fd9c5031b3db1538
- https://git.kernel.org/stable/c/59fa94cddf9eef8d8dae587373eed8b8f4eb11d7
- https://git.kernel.org/stable/c/6a90a44d53428a3bf01bd80df9ba78b19959270c
- https://git.kernel.org/stable/c/7759c3222815b945a94b212bc0c6cdec475cfec2
- https://git.kernel.org/stable/c/ab64ec2c75683f30ccde9eaaf0761002f901aa12
- https://git.kernel.org/stable/c/f2f0f8c18b60ca64ff50892ed899cf1c77864755
- https://git.kernel.org/stable/c/f5c68137f1191ba3fcf6260ec71b30be2e2bf4c3
Modified: 2025-10-01
CVE-2022-49351
In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/11ec18b1d8d92b9df307d31950dcba0b3dd7283c
- https://git.kernel.org/stable/c/1fd12298a0e0ca23478c715e672ee64c85670584
- https://git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de
- https://git.kernel.org/stable/c/5cd0e22fa11f4a21a8c09cc258f20b1474c95801
- https://git.kernel.org/stable/c/803b217f1fb49a2dbb2123acdb45111b9c48b8be
- https://git.kernel.org/stable/c/8174acbef87b8dd8bf3731eba2a5af1ac857e239
- https://git.kernel.org/stable/c/96bf5ed057df2d157274d4e2079002f9a9404bb8
- https://git.kernel.org/stable/c/a013fa884d8738ad8455aa1a843b8c9d80c6c833
- https://git.kernel.org/stable/c/e31d9ba169860687dba19bdc8fccbfd34077f655
Modified: 2025-10-01
CVE-2022-49354
In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid refcount leak.
- https://git.kernel.org/stable/c/10d6bdf532902be1d8aa5900b3c03c5671612aa2
- https://git.kernel.org/stable/c/19cb3ece14547cb1ca2021798aaf49a3f82643d1
- https://git.kernel.org/stable/c/7bd85c5ba1687daf54e3b6907673c3604b1e75cf
- https://git.kernel.org/stable/c/888312dc297a8a103f6371ef668c7e04f57a7679
- https://git.kernel.org/stable/c/8d8ad067b90f231b8fdb14acee673ca4012f6045
- https://git.kernel.org/stable/c/a4d3e5f1d7d4f8b5e3834fec0f057a762c55806b
- https://git.kernel.org/stable/c/c9782e1b21bee4b783a64b2a91e7e71406c21a21
- https://git.kernel.org/stable/c/d5a1e7f33c88780b279835d63665d7e38ccb671f
- https://git.kernel.org/stable/c/fb2cb409b504bb3a69e65a17f3120328c8e50219
Modified: 2025-10-01
CVE-2022-49367
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/02ded5a173619b11728b8bf75a3fd995a2c1ff28
- https://git.kernel.org/stable/c/42658e47f1abbbe592007d3ba303de466114d0bb
- https://git.kernel.org/stable/c/86c3c5f8e4bd1325e24f6fba9017cade29933377
- https://git.kernel.org/stable/c/8a1a1255152da4fb934290e7ababc66f24985520
- https://git.kernel.org/stable/c/a101793994c0a14c70bb4e44c7fda597eeebba0a
- https://git.kernel.org/stable/c/c1df9cb756e5a9ba1841648c44ee5d92306b9c65
- https://git.kernel.org/stable/c/dc1cf8c6f9793546696fded437a5b4c84944c48b
- https://git.kernel.org/stable/c/e0d763d0c7665c7897e4f5a0847ab0c82543345f
Modified: 2025-10-01
CVE-2022-49368
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() The "fsp->location" variable comes from user via ethtool_get_rxnfc(). Check that it is valid to prevent an out of bounds read.
- https://git.kernel.org/stable/c/0b238f75b65ed4462ef4cdfa718cac0ac7fce3b8
- https://git.kernel.org/stable/c/2bd1faedb74dc2a2be3972abcd4239b75a3e7b00
- https://git.kernel.org/stable/c/4cde554c70d7397cfa2e4116bacb4accdfb6fd48
- https://git.kernel.org/stable/c/5ba81f82607ead85fe36f50869fc4f5661359ab8
- https://git.kernel.org/stable/c/657e7174603f0aab2cdedc64ac81edffd2a87afe
- https://git.kernel.org/stable/c/71ae30662ec610b92644d13f79c78f76f17873b3
- https://git.kernel.org/stable/c/b24ca1cf846273361d5bd73a35de95a486a54b6d
- https://git.kernel.org/stable/c/b4f0e57ea0d867aacffad7999527e48bd4ea9293
- https://git.kernel.org/stable/c/e7e7104e2d5ddf3806a28695670f21bef471f1e1
Modified: 2025-10-01
CVE-2022-49370
In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put().
- https://git.kernel.org/stable/c/3ba359ebe914ac3f8c6c832b28007c14c39d3766
- https://git.kernel.org/stable/c/660ba678f9998aca6db74f2dd912fa5124f0fa31
- https://git.kernel.org/stable/c/985706bd3bbeffc8737bc05965ca8d24837bc7db
- https://git.kernel.org/stable/c/a724634b2a49f6ff0177a9e19a5a92fc1545e1b7
- https://git.kernel.org/stable/c/a9bfb37d6ba7c376b0d53337a4c5f5ff324bd725
- https://git.kernel.org/stable/c/c66cc3c62870a27ea8f060a7e4c1ad8d26dd3f0d
- https://git.kernel.org/stable/c/ec752973aa721ee281d5441e497364637c626c7b
- https://git.kernel.org/stable/c/ed38d04342dfbe9e5aca745c8b5eb4188a74f0ef
- https://git.kernel.org/stable/c/fdffa4ad8f6bf1ece877edfb807f2b2c729d8578
Modified: 2025-10-21
CVE-2022-49372
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_rtx_synack() can be called from process context
Laurent reported the enclosed report [1]
This bug triggers with following coditions:
0) Kernel built with CONFIG_DEBUG_PREEMPT=y
1) A new passive FastOpen TCP socket is created.
This FO socket waits for an ACK coming from client to be a complete
ESTABLISHED one.
2) A socket operation on this socket goes through lock_sock()
release_sock() dance.
3) While the socket is owned by the user in step 2),
a retransmit of the SYN is received and stored in socket backlog.
4) At release_sock() time, the socket backlog is processed while
in process context.
5) A SYNACK packet is cooked in response of the SYN retransmit.
6) -> tcp_rtx_synack() is called in process context.
Before blamed commit, tcp_rtx_synack() was always called from BH handler,
from a timer handler.
Fix this by using TCP_INC_STATS() & NET_INC_STATS()
which do not assume caller is in non preemptible context.
[1]
BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
caller is tcp_rtx_synack.part.0+0x36/0xc0
CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1
Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
Call Trace:
- https://git.kernel.org/stable/c/0a0f7f84148445c9f02f226928803a870139d820
- https://git.kernel.org/stable/c/0a375c822497ed6ad6b5da0792a12a6f1af10c0b
- https://git.kernel.org/stable/c/3db889f883e65bbd3b1401279bfc1e9ed255c481
- https://git.kernel.org/stable/c/58bd38cbc961fd799842b7be8c5222310f04b908
- https://git.kernel.org/stable/c/88cd232146207ff1d41dededed5e77c0d4438113
- https://git.kernel.org/stable/c/bdc28a8fb43cc476e33b11519235adb816ce00e8
- https://git.kernel.org/stable/c/c348b0f8d035fc4bdc040796889beec7218bd1b8
- https://git.kernel.org/stable/c/d05c2fdf8e10528bb6751bd95243e862d5402a9b
- https://git.kernel.org/stable/c/d8e1bc6029acac796293310aacef7b7336f35b6a
Modified: 2025-10-01
CVE-2022-49374
In the Linux kernel, the following vulnerability has been resolved: tipc: check attribute length for bearer name syzbot reported uninit-value: ===================================================== BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline] BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME. - Do not use 'illegal name' in printing message.
- https://git.kernel.org/stable/c/292be63c382ce20673ee61dff1ee9ed4a3dcaae7
- https://git.kernel.org/stable/c/3af15272cde28fe5c8489174b8624e232c1775ec
- https://git.kernel.org/stable/c/7f36f798f89bf32c0164049cb0e3fd1af613d0bb
- https://git.kernel.org/stable/c/8b91d0dfc839e67708c905648cd0e7507a2263e5
- https://git.kernel.org/stable/c/92a930fcf4250fe961f6238b99af0bc405799f39
- https://git.kernel.org/stable/c/b8fac8e321044a9ac50f7185b4e9d91a7745e4b0
- https://git.kernel.org/stable/c/f07670871f4d19e613740eebe210e7e9ea535973
Modified: 2025-10-01
CVE-2022-49375
In the Linux kernel, the following vulnerability has been resolved: rtc: mt6397: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value.
- https://git.kernel.org/stable/c/3867f0bbb94773d41e789257abec0d14f37da217
- https://git.kernel.org/stable/c/58a729c55ce3a432eb827fdaa24c7909cd3b0a6b
- https://git.kernel.org/stable/c/6ecd4d5c28408df36a1a6f0b1973f633c949ac1f
- https://git.kernel.org/stable/c/79fa3f5758d8712df0678df98161f948fc4370e5
- https://git.kernel.org/stable/c/82bfea344e8f7e9a0e0b1bf9af27552baa756620
- https://git.kernel.org/stable/c/865051de2d9eaa50630e055b73921ceaf3c4a7fc
- https://git.kernel.org/stable/c/d3b43eb505bffb8e4cdf6800c15660c001553fe6
- https://git.kernel.org/stable/c/d77f28c1bc9d3043a52069fe42e4a26fbf961ebd
- https://git.kernel.org/stable/c/da38e86d6cf6dd3bc65c602d998f357145aa1a0b
Modified: 2025-10-01
CVE-2022-49381
In the Linux kernel, the following vulnerability has been resolved:
jffs2: fix memory leak in jffs2_do_fill_super
If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns
an error, we can observe the following kmemleak report:
--------------------------------------------
unreferenced object 0xffff888105a65340 (size 64):
comm "mount", pid 710, jiffies 4302851558 (age 58.239s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/28048a4cf3813b7cf5cc8cce629dfdc7951cb1c2
- https://git.kernel.org/stable/c/3252d327f977b14663a10967f3b0930d6c325687
- https://git.kernel.org/stable/c/4ba7bbeab8009faf3a726e565d98816593ddd5b0
- https://git.kernel.org/stable/c/4da8763a3d2b684c773b72ed80fad40bc264bc40
- https://git.kernel.org/stable/c/69295267c481545f636b69ff341b8db75aa136b9
- https://git.kernel.org/stable/c/c14adb1cf70a984ed081c67e9d27bc3caad9537c
- https://git.kernel.org/stable/c/cf9db013e167bc8fc2ecd7a13ed97a37df0c9dab
- https://git.kernel.org/stable/c/d3a4fff1e7e408c32649030daa7c2c42a7e19a95
- https://git.kernel.org/stable/c/ecc53e58596542791e82eff00702f8af7a313f70
Modified: 2025-10-01
CVE-2022-49382
In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/042571fe1d171773655ad706715ecc865913d9a4
- https://git.kernel.org/stable/c/28133325526b92921f3269fdf97a20d90b92b217
- https://git.kernel.org/stable/c/5b3e990f85eb034faa461e691e719e8ce9e2a3c8
- https://git.kernel.org/stable/c/69a30b2ed620c2206cbbd1e9c112e4fc584e02bd
- https://git.kernel.org/stable/c/8f64e84924604bb969ee1fbc4b8d7d09b9214889
- https://git.kernel.org/stable/c/9b59588d8be91c96bfb0371e912ceb4f16315dbf
- https://git.kernel.org/stable/c/aab25b669cb9fd3698c2631be4435f4fe92d9e59
- https://git.kernel.org/stable/c/d5422f323858cad3ac3581075f9a3a5e0d41c0d8
Modified: 2025-03-25
CVE-2022-49388
In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-free when volume creation failed There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link].
- https://git.kernel.org/stable/c/1174ab8ba36a48025b68b5ff1085000b1e510217
- https://git.kernel.org/stable/c/25ff1e3a1351c0d936dd1ac2f9e58231ea1510c9
- https://git.kernel.org/stable/c/5ff2514e4fb55dcf3d88294686040ca73ea0c1a2
- https://git.kernel.org/stable/c/6d8d3f68cbecfd31925796f0fb668eb21ab06734
- https://git.kernel.org/stable/c/8302620aeb940f386817321d272b12411ae7d39f
- https://git.kernel.org/stable/c/8c03a1c21d72210f81cb369cc528e3fde4b45411
- https://git.kernel.org/stable/c/abb67043060f2bf4c03d7c3debb9ae980e2b6db3
- https://git.kernel.org/stable/c/e27ecf325e51abd06aaefba57a6322a46fa4178b
Modified: 2025-10-01
CVE-2022-49389
In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review.
- https://git.kernel.org/stable/c/11c65408bd0ba1d9cd1307caa38169292de9cdfb
- https://git.kernel.org/stable/c/247d3809e45a34d9e1a3a2bb7012e31ed8b46031
- https://git.kernel.org/stable/c/2f0ae93ec33c8456cdfbf7876b80403a6318ebce
- https://git.kernel.org/stable/c/51422046be504515eb5a591adf0f424b62f46804
- https://git.kernel.org/stable/c/6bafee2f18af5e5ac125e42960bc65496d0e56a0
- https://git.kernel.org/stable/c/8afb048800919d0ab10c57983940eba956339f21
- https://git.kernel.org/stable/c/9ec4cbf1cc55d126759051acfe328d489c5d6e60
- https://git.kernel.org/stable/c/bcbb795a9e78180d74c6ab21518da87e803dfdce
- https://git.kernel.org/stable/c/f20d2d3b3364ce6525c050a8b6b4c54c8c19674d
Modified: 2025-10-21
CVE-2022-49394
In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix inflight count imbalances and IO hangs on offline iolatency needs to track the number of inflight IOs per cgroup. As this tracking can be expensive, it is disabled when no cgroup has iolatency configured for the device. To ensure that the inflight counters stay balanced, iolatency_set_limit() freezes the request_queue while manipulating the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared.
- https://git.kernel.org/stable/c/515d077ee3085ae343b6bea7fd031f9906645f38
- https://git.kernel.org/stable/c/5b0ff3ebbef791341695b718f8d2870869cf1d01
- https://git.kernel.org/stable/c/77692c02e1517c54f2fd0535f41aa4286ac9f140
- https://git.kernel.org/stable/c/8a177a36da6c54c98b8685d4f914cb3637d53c0d
- https://git.kernel.org/stable/c/968f7a239c590454ffba79c126fbe0e963a0ba78
- https://git.kernel.org/stable/c/a30acbb5dfb7bcc813ad6a18ca31011ac44e5547
- https://git.kernel.org/stable/c/d19fa8f252000d141f9199ca32959c50314e1f05
Modified: 2025-10-01
CVE-2022-49395
In the Linux kernel, the following vulnerability has been resolved: um: Fix out-of-bounds read in LDT setup syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================
- https://git.kernel.org/stable/c/10995a382271254bd276627ec74136da4a23c4a6
- https://git.kernel.org/stable/c/24ca648bf5f72ed8878cf09b5d4431935779681e
- https://git.kernel.org/stable/c/2a4a62a14be1947fa945c5c11ebf67326381a568
- https://git.kernel.org/stable/c/3549ab4b962cf619e8c55484a0d870a34b3f845f
- https://git.kernel.org/stable/c/668ca34a428d6ffc0f99a1a6a9b661a288d4183b
- https://git.kernel.org/stable/c/91e5ba2af2d729d5126aefd5aa3eadc69b8426e5
- https://git.kernel.org/stable/c/9caad70819aef3431abaf73ba5163b55b161aba0
- https://git.kernel.org/stable/c/cf0dabc37446c5ee538ae7b4c467ab0e53fa5463
- https://git.kernel.org/stable/c/ef1dc929a1e5fa1b2d842256db9fb8710d3be910
Modified: 2025-09-22
CVE-2022-49396
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix reset-controller leak on probe errors Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral). Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly.
- https://git.kernel.org/stable/c/2156dc390402043ba5982489c6625adcb0b0975c
- https://git.kernel.org/stable/c/4d2900f20edfe541f75756a00deeb2ffe7c66bc1
- https://git.kernel.org/stable/c/7ac21b24af859c097eb4034e93430056068f8f31
- https://git.kernel.org/stable/c/8c03eb0c8982677b4e17174073a011788891304d
- https://git.kernel.org/stable/c/a39d9eccb333b8c07c43ebea1c6dfda122378a0f
- https://git.kernel.org/stable/c/b7b5fbcaac5355e2e695dc0c08a0fcf248250388
- https://git.kernel.org/stable/c/ba173a6f8d8dffed64bb13ab23081bdddfb464f0
- https://git.kernel.org/stable/c/feb05b10b3ed3ae21b851520a0d0b71685439517
Modified: 2025-09-22
CVE-2022-49397
In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix struct clk leak on probe errors Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral).
- https://git.kernel.org/stable/c/1668ad103679306ba2ef37f758d704e58a3ef1a0
- https://git.kernel.org/stable/c/621a4bcfb7aa031e7760d7b156bad7a45df58387
- https://git.kernel.org/stable/c/6f3673c8d8eff0c4ab5a5ee0d3ca9717d85419b4
- https://git.kernel.org/stable/c/ad9b0fad02f9b3a06ad5ac7df11f244e316a6254
- https://git.kernel.org/stable/c/b246695636a861a09f0e2cde92bb2dd8f114f024
- https://git.kernel.org/stable/c/b999d48b0869b8599de532ff6081575a7ab5358a
- https://git.kernel.org/stable/c/f0a4bc38a12f5a0cc5ad68670d9480e91e6a94df
- https://git.kernel.org/stable/c/f8d23895a41243c6a8dbf392e531fff9497bb023
Modified: 2025-10-21
CVE-2022-49399
In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Use tty_port_destroy() to destroy port In goldfish_tty_probe(), the port initialized through tty_port_init() should be destroyed in error paths.In goldfish_tty_remove(), qtty->port also should be destroyed or else might leak resources. Fix the above by calling tty_port_destroy().
- https://git.kernel.org/stable/c/241fcb79dd1df276d80b19f5f6acc9eaaaa63309
- https://git.kernel.org/stable/c/326192b99c903a2193d820c30ed936cc2402382c
- https://git.kernel.org/stable/c/45f6ce70abfb7ccf9d787781cbc4c03294a775a1
- https://git.kernel.org/stable/c/4639d1b992de8f37d66f698056875c274efcd45f
- https://git.kernel.org/stable/c/507b05063d1b7a1fcb9f7d7c47586fc4f3508f98
- https://git.kernel.org/stable/c/9ae3d073f7db5578ae1907544f0c15947e9678e6
- https://git.kernel.org/stable/c/da64f419d7f78272bfe40dde1262602d4ff6b32c
- https://git.kernel.org/stable/c/ee6c33b29e624f515202a31bf6ef0437f26a1867
Modified: 2025-10-01
CVE-2022-49404
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix potential integer multiplication overflow errors When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow.
- https://git.kernel.org/stable/c/06039d8afefdbac05bcea5f397188407eba2996d
- https://git.kernel.org/stable/c/252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a
- https://git.kernel.org/stable/c/31dca00d0cc9f4133320d72eb7e3720badc6d6e6
- https://git.kernel.org/stable/c/3f09ec80f115d2875d747ed28adc1773037e0f8b
- https://git.kernel.org/stable/c/79c164e61f818054cd6012e9035701840d895c51
- https://git.kernel.org/stable/c/8858284dd74906fa00f04f0252c75df4893a7959
- https://git.kernel.org/stable/c/a89cb7ddf6a89bab6012e19da38b7cdb26175c19
- https://git.kernel.org/stable/c/ef5ab2e48a5f9960e2352332b7cdb7064bb49032
- https://git.kernel.org/stable/c/f93e91a0372c922c20d5bee260b0f43b4b8a1bee
Modified: 2025-09-22
CVE-2022-49407
In the Linux kernel, the following vulnerability has been resolved: dlm: fix plock invalid read This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated---
- https://git.kernel.org/stable/c/2c55155cc365861044d9e6e80e342693e8805e33
- https://git.kernel.org/stable/c/42252d0d2aa9b94d168241710a761588b3959019
- https://git.kernel.org/stable/c/49cd9eb7b9a7b88124b31e31f8e539acaf1b3a6d
- https://git.kernel.org/stable/c/56aa8d1fbd02357f3bf81bdfba1cde87ce8402fc
- https://git.kernel.org/stable/c/5a1765adf9855cf0f6d3f7e0eb4b78ca66f70dee
- https://git.kernel.org/stable/c/72f2f68970f9bdc252d59e119b385a6441b0b155
- https://git.kernel.org/stable/c/899bc4429174861122f0c236588700a4710c1fec
- https://git.kernel.org/stable/c/acdad5bc9827922ec2f2e84fd198718aa8e8ab92
- https://git.kernel.org/stable/c/e421872fa17542cf33747071fb141b0130ce9ef7
Modified: 2025-10-01
CVE-2022-49410
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref().
- https://git.kernel.org/stable/c/058cb6d86b9789377216c936506b346aaa1eb581
- https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50
- https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e
- https://git.kernel.org/stable/c/99696a2592bca641eb88cc9a80c90e591afebd0f
- https://git.kernel.org/stable/c/bd83ff3bbfb003832481c9bff999d12385f396ae
- https://git.kernel.org/stable/c/c27f744ceefadc7bbeb14233b6abc150ced617d2
- https://git.kernel.org/stable/c/f8b383f83cb573152c577eca1ef101e89995b72a
Modified: 2025-03-24
CVE-2022-49416
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free in chanctx code In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx.
- https://git.kernel.org/stable/c/265bec4779a38b65e86a25120370f200822dfa76
- https://git.kernel.org/stable/c/2965c4cdf7ad9ce0796fac5e57debb9519ea721e
- https://git.kernel.org/stable/c/4ba81e794f0fad6234f644c2da1ae14d5b95e1c4
- https://git.kernel.org/stable/c/4f05a9e15edcdf5b97e0d86ab6ecd5f187289f6c
- https://git.kernel.org/stable/c/6118bbdf69f4718b02d26bbcf2e497eb66004331
- https://git.kernel.org/stable/c/82c8e7bbdd06c7ed58e22450cc5b37f33a25bb2c
- https://git.kernel.org/stable/c/88cc8f963febe192d6ded9df7217f92f380b449a
- https://git.kernel.org/stable/c/9f1e5cc85ad77e52f54049a94db0407445ae2a34
- https://git.kernel.org/stable/c/b79110f2bf6022e60e590d2e094728a8eec3e79e
Modified: 2025-09-22
CVE-2022-49421
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/2e2e2c71b2642289438392edbf5d08cdbc0b138b
- https://git.kernel.org/stable/c/38d245cebf545338a6bc1c7762023de3fbecd7b7
- https://git.kernel.org/stable/c/51eb1bb6baeb478538dd4ec6459fd68c44a855b1
- https://git.kernel.org/stable/c/6c92711db7c90f78e0b67ac2a8944d0fe7e12d83
- https://git.kernel.org/stable/c/8db59df7f5826e104db82cfddbf22a33a151193e
- https://git.kernel.org/stable/c/b23789a59fa6f00e98a319291819f91fbba0deb8
- https://git.kernel.org/stable/c/bbb2a24e863b6a10129546a0a4ceea2f07deec39
- https://git.kernel.org/stable/c/c1c4405222b6fc98c16e8c2aa679c14e41d81465
- https://git.kernel.org/stable/c/f2dfb4ab887d67be7d0892ba041d3c8d738d3356
Modified: 2025-10-22
CVE-2022-49425
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix dereference of stale list iterator after loop body The list iterator variable will be a bogus pointer if no break was hit. Dereferencing it (cur->page in this case) could load an out-of-bounds/undefined value making it unsafe to use that in the comparision to determine if the specific element was found. Since 'cur->page' *can* be out-ouf-bounds it cannot be guaranteed that by chance (or intention of an attacker) it matches the value of 'page' even though the correct element was not found. This is fixed by using a separate list iterator variable for the loop and only setting the original variable if a suitable element was found. Then determing if the element was found is simply checking if the variable is set.
- https://git.kernel.org/stable/c/2aaf51dd39afb6d01d13f1e6fe20b684733b37d5
- https://git.kernel.org/stable/c/385edd3ce5b4b1e9d31f474a5e35a39779ec1110
- https://git.kernel.org/stable/c/45b2b7d7108ae1e25a5036cab04ab9273e792332
- https://git.kernel.org/stable/c/51d584704d18e60fa473823654f35611c777b291
- https://git.kernel.org/stable/c/5e47a7add3dda7f236548c5ec3017776dc2a729f
- https://git.kernel.org/stable/c/b26e1c777890e4b938136deb8ec07a29f33862e4
- https://git.kernel.org/stable/c/ed7efc472c00986dcd6903ab6ed165c7fa167674
Modified: 2025-10-22
CVE-2022-49429
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent panic when SDMA is disabled If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.
- https://git.kernel.org/stable/c/0e4dda8b3f4c07ee9ea670a10ea3171a5e63a86f
- https://git.kernel.org/stable/c/22e7e400fd1a890db2ea13686324aff50e972f4f
- https://git.kernel.org/stable/c/29952ab85d6c3fe0b7909d9a737f10c58bf6824d
- https://git.kernel.org/stable/c/32e6aea33944f364d51cd263e4cd236393a188b6
- https://git.kernel.org/stable/c/33794e8e9bcb4affc0ebff9cdec85acc8b8a1762
- https://git.kernel.org/stable/c/629e052d0c98e46dde9f0824f0aa437f678d9b8f
- https://git.kernel.org/stable/c/cc80d3c37cec9d6ddb140483647901bc7cc6c31d
- https://git.kernel.org/stable/c/e60ad83f645ee6fadd5a8057ba267aeec54f08fe
Modified: 2025-10-22
CVE-2022-49432
In the Linux kernel, the following vulnerability has been resolved: powerpc/xics: fix refcount leak in icp_opal_init() The of_find_compatible_node() function returns a node pointer with refcount incremented, use of_node_put() on it when done.
- https://git.kernel.org/stable/c/1d5c8cea85fb1680eae8d645b96b92146cb4633c
- https://git.kernel.org/stable/c/2357bd7499a81c70b460e2191852bbfc7b63c354
- https://git.kernel.org/stable/c/537a317e5ff45d1f5a0ecaf6a0d7c8043c878cb1
- https://git.kernel.org/stable/c/53f3f7f73e609b934083f896cb7ca2c2cb009b9f
- https://git.kernel.org/stable/c/5dd9e27ea4a39f7edd4bf81e9e70208e7ac0b7c9
- https://git.kernel.org/stable/c/6a61a97106279c2aa16fbbb2a171fd5dde127d23
- https://git.kernel.org/stable/c/977dbc81d0f866ef63b93c127b7404f07734b3cc
- https://git.kernel.org/stable/c/9a42bc2494fadb453de00ce61042e588563ddc6d
- https://git.kernel.org/stable/c/df802880a7f9cd96b921b00639b00871f18a9a57
Modified: 2025-10-22
CVE-2022-49433
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent use of lock before it is initialized If there is a failure during probe of hfi1 before the sdma_map_lock is initialized, the call to hfi1_free_devdata() will attempt to use a lock that has not been initialized. If the locking correctness validator is on then an INFO message and stack trace resembling the following may be seen: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Call Trace: register_lock_class+0x11b/0x880 __lock_acquire+0xf3/0x7930 lock_acquire+0xff/0x2d0 _raw_spin_lock_irq+0x46/0x60 sdma_clean+0x42a/0x660 [hfi1] hfi1_free_devdata+0x3a7/0x420 [hfi1] init_one+0x867/0x11a0 [hfi1] pci_device_probe+0x40e/0x8d0 The use of sdma_map_lock in sdma_clean() is for freeing the sdma_map memory, and sdma_map is not allocated/initialized until after sdma_map_lock has been initialized. This code only needs to be run if sdma_map is not NULL, and so checking for that condition will avoid trying to use the lock before it is initialized.
- https://git.kernel.org/stable/c/05c03dfd09c069c4ffd783b47b2da5dcc9421f2c
- https://git.kernel.org/stable/c/288d198f50434f29b4a26a9de4394ae2305ad8af
- https://git.kernel.org/stable/c/30eb275e7ed588270ae159cc590a96658e0cfd8f
- https://git.kernel.org/stable/c/66090815a24ce14cf51ef5453fc0218fe8a39bc2
- https://git.kernel.org/stable/c/addb192000d8819c0b1553453994df9bb54c28db
- https://git.kernel.org/stable/c/ca55150bff5817af4f857a746ecab9862c23e12a
- https://git.kernel.org/stable/c/fc0750e659db7b315bf6348902cc8ca3cdd4b8d8
Modified: 2025-12-23
CVE-2022-49434
In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() The sysfs sriov_numvfs_store() path acquires the device lock before the config space access lock: sriov_numvfs_store device_lock # A (1) acquire device lock sriov_configure vfio_pci_sriov_configure # (for example) vfio_pci_core_sriov_configure pci_disable_sriov sriov_disable pci_cfg_access_lock pci_wait_cfg # B (4) wait for dev->block_cfg_access == 0 Previously, pci_dev_lock() acquired the config space access lock before the device lock: pci_dev_lock pci_cfg_access_lock dev->block_cfg_access = 1 # B (2) set dev->block_cfg_access = 1 device_lock # A (3) wait for device lock Any path that uses pci_dev_lock(), e.g., pci_reset_function(), may deadlock with sriov_numvfs_store() if the operations occur in the sequence (1) (2) (3) (4). Avoid the deadlock by reversing the order in pci_dev_lock() so it acquires the device lock before the config space access lock, the same as the sriov_numvfs_store() path. [bhelgaas: combined and adapted commit log from Jay Zhou's independent subsequent posting: https://lore.kernel.org/r/20220404062539.1710-1-jianjay.zhou@huawei.com]
- https://git.kernel.org/stable/c/2cdd5284035322795b0964f899eefba254cfe483
- https://git.kernel.org/stable/c/59ea6b3ae51df7cd6bfd84c9c0030609b9315622
- https://git.kernel.org/stable/c/a91ee0e9fca9d7501286cfbced9b30a33e52740a
- https://git.kernel.org/stable/c/aed6d4d519210c28817948f34c53b6e058e0456c
- https://git.kernel.org/stable/c/c3c6dc1853b8bf3c718f96fd8480a6eb09ba4831
- https://git.kernel.org/stable/c/c9a81f9ed6ae3554621d6a50220b1bc74b67d81e
- https://git.kernel.org/stable/c/ea047f51172aa68841adef7f52d375002438b8f0
- https://git.kernel.org/stable/c/eff3587b9c01439b738298475e555c028ac9f55e
Modified: 2025-10-01
CVE-2022-49438
In the Linux kernel, the following vulnerability has been resolved: Input: sparcspkr - fix refcount leak in bbc_beep_probe of_find_node_by_path() calls of_find_node_opts_by_path(), which returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1124e39fea0e2fdb4202f95b716cb97cc7de7cc7
- https://git.kernel.org/stable/c/2f51db16cb740ff90086189a1ef2581eab665591
- https://git.kernel.org/stable/c/353bc58ac6c782d4dcde9136a91d1f90867938fe
- https://git.kernel.org/stable/c/418b6a3e12f75638abc5673eb76cb32127d0ab13
- https://git.kernel.org/stable/c/6e07ccc7d56130f760d23f67a70c45366c07debc
- https://git.kernel.org/stable/c/73d6f42d8d86648bec2e73d34fe1648cb6d23e08
- https://git.kernel.org/stable/c/bbc2b0ce6042dd3117827f10ea8cb67e0ab786da
- https://git.kernel.org/stable/c/c8994b30d71d64d5dcc9bc0edbfdf367171aa96f
- https://git.kernel.org/stable/c/f13064b0f2c651a3fbb0749932795c6fd21556a8
Modified: 2025-10-01
CVE-2022-49439
In the Linux kernel, the following vulnerability has been resolved: powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/46fd994763cf6884b88a2da712af918f3ed54d7b
- https://git.kernel.org/stable/c/51e25fbf20c9152d84a34b7afac15a41fe5c9116
- https://git.kernel.org/stable/c/5607a77a365df8c0fd5ff43ac424812b95775527
- https://git.kernel.org/stable/c/5b8aa2ba38c010f47c965dd9bb5a8561813ed649
- https://git.kernel.org/stable/c/7b668a59ddfb32727e39b06fdf52b28e58c684e0
- https://git.kernel.org/stable/c/bcb6c4c5eb4836a21411dfe8247bf9951eb6e7c3
- https://git.kernel.org/stable/c/c70dd353d37158e06bf8d450d4b31a7091609924
- https://git.kernel.org/stable/c/fcee96924ba1596ca80a6770b2567ca546f9a482
Modified: 2025-10-01
CVE-2022-49441
In the Linux kernel, the following vulnerability has been resolved: tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated---
- https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314
- https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50
- https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded
- https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28
- https://git.kernel.org/stable/c/4af21b12a60ed2d3642284f4f85b42d7dc6ac246
- https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9
- https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3
- https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede
- https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6
Modified: 2025-10-22
CVE-2022-49442
In the Linux kernel, the following vulnerability has been resolved: drivers/base/node.c: fix compaction sysfs file leak Compaction sysfs file is created via compaction_register_node in register_node. But we forgot to remove it in unregister_node. Thus compaction sysfs file is leaked. Using compaction_unregister_node to fix this issue.
- https://git.kernel.org/stable/c/386e69e068177ee91cac27f2f0e6ebda1515f5ca
- https://git.kernel.org/stable/c/39642b0feddb9c39faa6de469a94bfeb4dc0d3a9
- https://git.kernel.org/stable/c/466134df7561aeb801baddf6666b512e0e1a1707
- https://git.kernel.org/stable/c/606732650a2c88e66c59c22dd5464ea0d820250e
- https://git.kernel.org/stable/c/6905be93d1ab54f73718047536fec0ca488d5315
- https://git.kernel.org/stable/c/b3fcf1f583b1a0946d9d9bfb7362c9c186801775
- https://git.kernel.org/stable/c/d8a5bdc767f17281da648555cdbd286f98fd98ee
- https://git.kernel.org/stable/c/da63dc84befaa9e6079a0bc363ff0eaa975f9073
- https://git.kernel.org/stable/c/f76ddc8fcf6d81fe89bfa4d3efcbc4fe69a91d48
Modified: 2025-10-01
CVE-2022-49447
In the Linux kernel, the following vulnerability has been resolved: ARM: hisi: Add missing of_node_put after of_find_compatible_node of_find_compatible_node will increment the refcount of the returned device_node. Calling of_node_put() to avoid the refcount leak
- https://git.kernel.org/stable/c/21a3effe446dd6dc5eed7fe897c2f9b88c9a5d6d
- https://git.kernel.org/stable/c/45d211668d33c49d73f5213e8c2b58468108647c
- https://git.kernel.org/stable/c/46cb7868811d025c3d29c10d18b3422db1cf20d5
- https://git.kernel.org/stable/c/9bc72e47d4630d58a840a66a869c56b29554cfe4
- https://git.kernel.org/stable/c/a3265a9440030068547a20dfee646666f3ca5278
- https://git.kernel.org/stable/c/cafaaae4bb9ce84a2791fa29bf6907a9466c3883
- https://git.kernel.org/stable/c/dd4be8ecfb41a29e7c4e551b4e866157ce4a3429
- https://git.kernel.org/stable/c/e109058165137ef42841abd989f080adfefa14fa
- https://git.kernel.org/stable/c/f8da78b2bae1f54746647a2bb44f8bd6025c57af
Modified: 2025-10-01
CVE-2022-49450
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix listen() setting the bar too high for the prealloc rings
AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump
up the sysctl), but whilst the preallocation circular buffers have 32 slots
in them, one of them has to be a dead slot because we're using CIRC_CNT().
This means that listen(rxrpc_sock, 32) will cause an oops when the socket
is closed because rxrpc_service_prealloc_one() allocated one too many calls
and rxrpc_discard_prealloc() won't then be able to get rid of them because
it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries
to abort them, but oopses because call->peer isn't yet set.
Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match
the ring capacity.
BUG: kernel NULL pointer dereference, address: 0000000000000086
...
RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc]
Call Trace:
- https://git.kernel.org/stable/c/369de57492c4f1a42563c5a3bd365822ca3bfc79
- https://git.kernel.org/stable/c/4a3a78b7918bdd723d8c7c9786522ca969bffcc4
- https://git.kernel.org/stable/c/5b4826657d36c218e9f08e8d3223b0edce3de88f
- https://git.kernel.org/stable/c/616f76498d5ddf26b997caf64a95cda3c8a55533
- https://git.kernel.org/stable/c/61fb38cfbb1d54d3dafd0c25752f684b3cd00b32
- https://git.kernel.org/stable/c/88e22159750b0d55793302eeed8ee603f5c1a95c
- https://git.kernel.org/stable/c/91b34bf0409f43bb60453bab23c5beadd726d022
- https://git.kernel.org/stable/c/b3a9b227d5e7467b8518160ff034ea22bb9de573
- https://git.kernel.org/stable/c/e198f1930050e3115c80b67d9249f80f98a27c67
Modified: 2025-10-01
CVE-2022-49451
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix list protocols enumeration in the base protocol While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough. Fix the validation avoiding the addition.
- https://git.kernel.org/stable/c/1052f22e127d0c34c3387bb389424ba1c61491ff
- https://git.kernel.org/stable/c/2ccfcd7a09c826516edcfe464b05071961aada3f
- https://git.kernel.org/stable/c/444a2d27fe9867d0da4b28fc45b793f32e099ab8
- https://git.kernel.org/stable/c/6e7978695f4a6cbd83616b5a702b77fa2087b247
- https://git.kernel.org/stable/c/8009120e0354a67068e920eb10dce532391361d0
- https://git.kernel.org/stable/c/98342148a8cd242855d7e257f298c966c96dba9f
- https://git.kernel.org/stable/c/b0e4bafac8963c2d85ee18d3d01f393735acceec
Modified: 2025-10-01
CVE-2022-49457
In the Linux kernel, the following vulnerability has been resolved: ARM: versatile: Add missing of_node_put in dcscb_init The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/23b44f9c649bbef10b45fa33080cd8b4166800ae
- https://git.kernel.org/stable/c/2d7b23db35254b7d46e852967090c64cdccf24da
- https://git.kernel.org/stable/c/3c6006faed9aba5144b33176d061031a9be66954
- https://git.kernel.org/stable/c/83c329b980bddbc8c6a3d287d91f2103a4d4a860
- https://git.kernel.org/stable/c/a0fc05cd17617e63fc13ad0c01f3f0afd890d8ec
- https://git.kernel.org/stable/c/bbdfb7d4f036118d36415a2575efa6f5246505ae
- https://git.kernel.org/stable/c/d146e2a9864ade19914494de3fb520390b415d58
- https://git.kernel.org/stable/c/d6de7b181c29cd4578ec139aafb5eac062abbe1b
- https://git.kernel.org/stable/c/fcd1999ba97445a12cc394f5f42ffd9116bf0185
Modified: 2025-10-22
CVE-2022-49460
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: rk3399_dmc: Disable edev on remove() Otherwise we hit an unablanced enable-count when unbinding the DFI device: [ 1279.659119] ------------[ cut here ]------------ [ 1279.659179] WARNING: CPU: 2 PID: 5638 at drivers/devfreq/devfreq-event.c:360 devfreq_event_remove_edev+0x84/0x8c ... [ 1279.659352] Hardware name: Google Kevin (DT) [ 1279.659363] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 1279.659371] pc : devfreq_event_remove_edev+0x84/0x8c [ 1279.659380] lr : devm_devfreq_event_release+0x1c/0x28 ... [ 1279.659571] Call trace: [ 1279.659582] devfreq_event_remove_edev+0x84/0x8c [ 1279.659590] devm_devfreq_event_release+0x1c/0x28 [ 1279.659602] release_nodes+0x1cc/0x244 [ 1279.659611] devres_release_all+0x44/0x60 [ 1279.659621] device_release_driver_internal+0x11c/0x1ac [ 1279.659629] device_driver_detach+0x20/0x2c [ 1279.659641] unbind_store+0x7c/0xb0 [ 1279.659650] drv_attr_store+0x2c/0x40 [ 1279.659663] sysfs_kf_write+0x44/0x58 [ 1279.659672] kernfs_fop_write_iter+0xf4/0x190 [ 1279.659684] vfs_write+0x2b0/0x2e4 [ 1279.659693] ksys_write+0x80/0xec [ 1279.659701] __arm64_sys_write+0x24/0x30 [ 1279.659714] el0_svc_common+0xf0/0x1d8 [ 1279.659724] do_el0_svc_compat+0x28/0x3c [ 1279.659738] el0_svc_compat+0x10/0x1c [ 1279.659746] el0_sync_compat_handler+0xa8/0xcc [ 1279.659758] el0_sync_compat+0x188/0x1c0 [ 1279.659768] ---[ end trace cec200e5094155b4 ]---
- https://git.kernel.org/stable/c/2fccf9e6050e0e3b8b4cd275d41daf7f7fa22804
- https://git.kernel.org/stable/c/664736e2cc09e504ce58ec61164d029d1f2651bb
- https://git.kernel.org/stable/c/86b091b6894c449d2734de7aa7d79ccb33ffd97d
- https://git.kernel.org/stable/c/a0180e324a9a63de8f770da300477b48cb4a53f1
- https://git.kernel.org/stable/c/a9c2b23a7ac6ab19214cad8cac8af8608a4d9cef
- https://git.kernel.org/stable/c/cb1be1d4be18fe286ba5a67d928598378fd7fbe5
- https://git.kernel.org/stable/c/fb089b6f21de03a685dd31df3789bbb01c59f8e3
Modified: 2025-10-01
CVE-2022-49467
In the Linux kernel, the following vulnerability has been resolved: drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails.
- https://git.kernel.org/stable/c/33546183c16c7b9650682dc610bedd732d9c6919
- https://git.kernel.org/stable/c/449374565f349d4233beec811d4286fdfe5de44b
- https://git.kernel.org/stable/c/656aa3c51fc662064f17179b38ec3ce43af53bca
- https://git.kernel.org/stable/c/947a844bb3ebff0f4736d244d792ce129f6700d7
- https://git.kernel.org/stable/c/d544880482a5558ec06393b1b3d5dc9275b7a32b
- https://git.kernel.org/stable/c/d63ffe3fb3f8327ca21cf91b6a14a2961bc629b4
- https://git.kernel.org/stable/c/f8cd192752a1f613b14eee77783c6f0aebb49691
Modified: 2025-10-01
CVE-2022-49472
In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Allow probing without .driver_data Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type.
- https://git.kernel.org/stable/c/143878e18001c5a61fcc7ae5c5240323753bb641
- https://git.kernel.org/stable/c/1e5fbfc2a6f384e3195446c14bbd3bc298eb88c2
- https://git.kernel.org/stable/c/660dfa033ccc9afb032015b6dc76e846bba42cfb
- https://git.kernel.org/stable/c/7dcb404662839a4ed1a9703658fee979eb894ca4
- https://git.kernel.org/stable/c/91e720b32cba25fa58eaa4c88fe957009cffe9f3
- https://git.kernel.org/stable/c/abb5594ae2ba7b82cce85917cc6337ec5d774837
- https://git.kernel.org/stable/c/bd219273b4e004a3f853da72e111fc8f81357501
- https://git.kernel.org/stable/c/f2ef6f7539c68c6bd6c32323d8845ee102b7c450
Modified: 2025-03-24
CVE-2022-49474
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/0x30
- https://git.kernel.org/stable/c/36c644c63bfcaee2d3a426f45e89a9cd09799318
- https://git.kernel.org/stable/c/390d82733a953c1fabf3de9c9618091a7a9c90a6
- https://git.kernel.org/stable/c/537f619dea4e3fa8ed1f8f938abffe3615794bcc
- https://git.kernel.org/stable/c/65d347cb39e2e6bd0c2a745ad7c928998ebb0162
- https://git.kernel.org/stable/c/6f55fac0af3531cf60d11369454c41f5fc81ab3f
- https://git.kernel.org/stable/c/7aa1e7d15f8a5b65f67bacb100d8fc033b21efa2
- https://git.kernel.org/stable/c/7d61dbd7311ab978d8ddac1749a758de4de00374
- https://git.kernel.org/stable/c/99df16007f4bbf9abfc3478cb17d10f0d7f8906e
- https://git.kernel.org/stable/c/9de3dc09e56f8deacd2bdbf4cecb71e11a312405
Modified: 2025-10-01
CVE-2022-49478
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work.
- https://git.kernel.org/stable/c/1310fc3538dcc375a2f46ef0a438512c2ca32827
- https://git.kernel.org/stable/c/24e807541e4a9263ed928e6ae3498de3ad43bd1e
- https://git.kernel.org/stable/c/2e004fe914b243db41fa96f9e583385f360ea58e
- https://git.kernel.org/stable/c/3309c2c574e13b21b44729f5bdbf21f60189b79a
- https://git.kernel.org/stable/c/4351bfe36aba9fa7dc9d68d498d25d41a0f45e67
- https://git.kernel.org/stable/c/471bec68457aaf981add77b4f590d65dd7da1059
- https://git.kernel.org/stable/c/a3304766d9384886e6d3092c776273526947a2e9
- https://git.kernel.org/stable/c/a3660e06675bccec4bf149c7229ea1d491ba10d7
- https://git.kernel.org/stable/c/f99a8b1ec0eddc2931aeaa4f490277a15b39f511
Modified: 2025-10-01
CVE-2022-49481
In the Linux kernel, the following vulnerability has been resolved: regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore.
- https://git.kernel.org/stable/c/0be5d9da5743b9825a95baec85a67500b2c1d362
- https://git.kernel.org/stable/c/49d785baeb91568332197be356d138e5e59c7ddb
- https://git.kernel.org/stable/c/56ab0c01027492cd161c64148e1dc892c56887ad
- https://git.kernel.org/stable/c/671be14fc31374b1a10a3abd93db6a8480838fc9
- https://git.kernel.org/stable/c/6ca675f4abbc74bc991d154a1ecc8b384dc2aae4
- https://git.kernel.org/stable/c/984cfef0675ed7398814e14af2c5323911723e1c
- https://git.kernel.org/stable/c/9f564e29a51210a49df3d925117777c157a17d6d
- https://git.kernel.org/stable/c/afaa7b933ef00a2d3262f4d1252087613fb5c06d
- https://git.kernel.org/stable/c/b74c0dd9179d21b7260260e075d597b23970100c
Modified: 2025-10-01
CVE-2022-49482
In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done.
- https://git.kernel.org/stable/c/18b907ff0ae4bf20120aae1538f7156b9d08e3a7
- https://git.kernel.org/stable/c/24491124406666bf0dcb9ee10c5575c6ce6a1730
- https://git.kernel.org/stable/c/2a0da7641e1f17a744ac7b3f76471388c97b63dc
- https://git.kernel.org/stable/c/2be84f73785fa9ed6443e3c5b158730266f1c2ee
- https://git.kernel.org/stable/c/30d110ca703ce60162ec337aa564a3e4da30715f
- https://git.kernel.org/stable/c/4e2a1bcc51bdebed48176f6e88c150f175983f9c
- https://git.kernel.org/stable/c/c933829cbf3338b684869e6c4c8931abf5d68fbd
- https://git.kernel.org/stable/c/d42601e93fce7802bb8d70dd59b60cfeefa20469
- https://git.kernel.org/stable/c/d855505851ee8ba666eb204149b49f906130dc17
Modified: 2025-10-22
CVE-2022-49488
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_mixer_release when deadlock is detected There is a possibility for mdp5_get_global_state to return -EDEADLK when acquiring the modeset lock, but currently global_state in mdp5_mixer_release doesn't check for if an error is returned. To avoid a NULL dereference error, let's have mdp5_mixer_release check if an error is returned and propagate that error. Patchwork: https://patchwork.freedesktop.org/patch/485181/
- https://git.kernel.org/stable/c/09bdeedc1fc53e64b8282e1de67752c69e43bdba
- https://git.kernel.org/stable/c/1a5d1474026ea4f1a6f931075ca2adb884af39cf
- https://git.kernel.org/stable/c/22d8424913b1348c6324916745fadaeea5273f0e
- https://git.kernel.org/stable/c/46e5ce63924a96af452c4fc5ee0bb3b241e1b9f4
- https://git.kernel.org/stable/c/47e393061049aff6818d1b9fdca7351411a23fc2
- https://git.kernel.org/stable/c/883f1d52a57bf51e1d7a80c432345e2c6222477e
- https://git.kernel.org/stable/c/ca75f6f7c6f89365e40f10f641b15981b1f07c31
Modified: 2025-03-24
CVE-2022-49489
In the Linux kernel, the following vulnerability has been resolved: drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag]
- https://git.kernel.org/stable/c/134760263f6441741db0b2970e7face6b34b6d1c
- https://git.kernel.org/stable/c/5b0adf5cbf3b74721e4e4c4e0cadc91b8df8bcc2
- https://git.kernel.org/stable/c/97ac682b6f7d36be5d934f86c9911066540a68f1
- https://git.kernel.org/stable/c/aa4cb188988dc6f1b3f4917d4dbc452150a5d871
- https://git.kernel.org/stable/c/ef10d0c68e8608848cd58fca2589685718426607
- https://git.kernel.org/stable/c/ef4bdaac7cb5416f236613ed9337ff0ea8ee329b
- https://git.kernel.org/stable/c/fa5186b279ecf44b14fb435540d2065be91cb1ed
Modified: 2025-10-22
CVE-2022-49490
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring the modeset lock, but currently mdp5_pipe_release doesn't check for if an error is returned. Because of this, there is a possibility of mdp5_pipe_release hitting a NULL dereference error. To avoid this, let's have mdp5_pipe_release check if mdp5_get_global_state returns an error and propogate that error. Changes since v1: - Separated declaration and initialization of *new_state to avoid compiler warning - Fixed some spelling mistakes in commit message Changes since v2: - Return 0 in case where hwpipe is NULL as this is considered normal behavior - Added 2nd patch in series to fix a similar NULL dereference issue in mdp5_mixer_release Patchwork: https://patchwork.freedesktop.org/patch/485179/
- https://git.kernel.org/stable/c/04bef5f1ba8ea6d7c1c8f5f65e0395c62db59cb8
- https://git.kernel.org/stable/c/19964dfb39bda4d7716a71009488f0668ecbcf52
- https://git.kernel.org/stable/c/33dc5aac46e0fad8f5eb193e5906ed0eb6b66ceb
- https://git.kernel.org/stable/c/49dc28b4b2e28ef7564e355c91487996c1cbebd7
- https://git.kernel.org/stable/c/776f5c58bfe16cf322d71eeed3c5dda1eeac7e6b
- https://git.kernel.org/stable/c/b2aa2c4efe93e2580d6a8774b04fe2b99756a322
- https://git.kernel.org/stable/c/d59be579fa932c46b908f37509f319cbd4ca9a68
Modified: 2025-10-01
CVE-2022-49491
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref.
- https://git.kernel.org/stable/c/3451852312303d54a003c73bd0ae39cebb960bd5
- https://git.kernel.org/stable/c/452922955df215a417c80d09dab72bbc667a1861
- https://git.kernel.org/stable/c/6ff986e057bf28e2f7690dad410768b2270f9453
- https://git.kernel.org/stable/c/769c53bb6116d0eaec0f1fe4ec4b27a74465cad1
- https://git.kernel.org/stable/c/a9b4599665e437de8a1152799c34841b799a2e1c
- https://git.kernel.org/stable/c/b54926bd558d97c888c3d2d87886f3c159d3254a
- https://git.kernel.org/stable/c/ecfa52654d0c9c333c1fe1611f47105f6bce9591
- https://git.kernel.org/stable/c/f8c242908ad15bbd604d3bcb54961b7d454c43f8
- https://git.kernel.org/stable/c/fcd6a886443730c39170b8383411e52118aec0a3
Modified: 2025-10-01
CVE-2022-49492
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference.
- https://git.kernel.org/stable/c/54a4c1e47d1b2585e74920399455bd9abbfb2bd7
- https://git.kernel.org/stable/c/7a28556082d1fbcbc599baf1c24252dfc73efefc
- https://git.kernel.org/stable/c/8321b17789f614414206af07e17ce4751c95dc76
- https://git.kernel.org/stable/c/8da2b7bdb47e94bbc4062a3978c708926bcb022c
- https://git.kernel.org/stable/c/906c81dba8ee8057523859b5e1a2479e9fd34860
- https://git.kernel.org/stable/c/9e649471b396fa0139d53919354ce1eace9b9a24
- https://git.kernel.org/stable/c/af98940dd33c9f9e1beb4f71c0a39260100e2a65
- https://git.kernel.org/stable/c/da42761181627e9bdc37d18368b827948a583929
- https://git.kernel.org/stable/c/f76729662650cd7bc8f8194e057af381370349a7
Modified: 2025-09-03
CVE-2022-49493
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix errorenous cleanup order There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync.
- https://git.kernel.org/stable/c/061a6159cea583f1155f67d1915917a6b9282662
- https://git.kernel.org/stable/c/0941150100173d4eaf3fe08ff4b16740e7c3026f
- https://git.kernel.org/stable/c/1a5a3dfd9f172dcb115072f0aea5e27d3083c20e
- https://git.kernel.org/stable/c/236d29c5857f02e0a53fdf15d3dce1536c4322ce
- https://git.kernel.org/stable/c/2def44d3aec59e38d2701c568d65540783f90f2f
- https://git.kernel.org/stable/c/453f0920ffc1a28e28ddb9c3cd5562472b2895b0
- https://git.kernel.org/stable/c/88c09e4812d72c3153afc8e5a45ecac2d0eae3ff
- https://git.kernel.org/stable/c/abe7554da62cb489712a54de69ef5665c250e564
Modified: 2025-10-01
CVE-2022-49495
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/
- https://git.kernel.org/stable/c/0978fcce91b90b561b8c82e7c492ba9fc8440eef
- https://git.kernel.org/stable/c/2b3ed7547b1a052209da6c4ab886ffe0eed88c42
- https://git.kernel.org/stable/c/4cd66a8016b872a153bf892fe4258cbc0dacf5b1
- https://git.kernel.org/stable/c/6369dda4a2209142ab819f01d3d2076d81e3ebdd
- https://git.kernel.org/stable/c/9cb1ee33efccb8b107ee04b7b3441820de3fd2da
- https://git.kernel.org/stable/c/9f5495a5c51c1d11c6ffc13aa2befffec0c2651a
- https://git.kernel.org/stable/c/a36e506711548df923ceb7ec9f6001375be799a5
- https://git.kernel.org/stable/c/c1bfacf0daf25a5fc7d667399d6ff2dffda84cd8
- https://git.kernel.org/stable/c/d9cb951d11a4ace4de5c50b1178ad211de17079e
Modified: 2025-10-21
CVE-2022-49503
In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyix The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()'
- https://git.kernel.org/stable/c/0bcb528402cd5e1a6e1833e956fd58a12d509e8e
- https://git.kernel.org/stable/c/2326d398ccd41ba6d93b8346532dfa432ab00fee
- https://git.kernel.org/stable/c/2dc509305cf956381532792cb8dceef2b1504765
- https://git.kernel.org/stable/c/3dad3fed5672828c7fb0465cb66a3d9a70952fa6
- https://git.kernel.org/stable/c/461e4c1f199076275f16bf6f3d3e42c6b6c79f33
- https://git.kernel.org/stable/c/4bdcf32c965c27f55ccc4ee71c1927131115b0bb
- https://git.kernel.org/stable/c/7f6defe0fabc79f29603c6fa3c80e4fe0456a3e9
- https://git.kernel.org/stable/c/a048e0c3caa852397b7b50d4c82a0415c05f7ac3
- https://git.kernel.org/stable/c/eda518db7db16c360bc84379d90675650daa3048
Modified: 2025-03-24
CVE-2022-49505
In the Linux kernel, the following vulnerability has been resolved:
NFC: NULL out the dev->rfkill to prevent UAF
Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")
assumes the device_is_registered() in function nfc_dev_up() will help
to check when the rfkill is unregistered. However, this check only
take effect when device_del(&dev->dev) is done in nfc_unregister_device().
Hence, the rfkill object is still possible be dereferenced.
The crash trace in latest kernel (5.18-rc2):
[ 68.760105] ==================================================================
[ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750
[ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313
[ 68.760756]
[ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4
[ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 68.760756] Call Trace:
[ 68.760756]
- https://git.kernel.org/stable/c/1632be63862f183cd5cf1cc094e698e6ec005dfd
- https://git.kernel.org/stable/c/1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9
- https://git.kernel.org/stable/c/2a1b5110c95e4d49c8c3906270dfcde680a5a7be
- https://git.kernel.org/stable/c/4a68938f43b7c2663e4c90bb9bbe29ac8b9a42a0
- https://git.kernel.org/stable/c/4f5d71930f41be78557f9714393179025baacd65
- https://git.kernel.org/stable/c/6abfaca8711803d0d7cc8c0fac1070a88509d463
- https://git.kernel.org/stable/c/a8e03bcad52dc9afabf650fdbad84f739cec9efa
- https://git.kernel.org/stable/c/f81270125b50532624400063281e6611ecd61ddf
- https://git.kernel.org/stable/c/fbf9c4c714d3cdeb98b6a18e4d057f931cad1d81
Modified: 2025-10-01
CVE-2022-49508
In the Linux kernel, the following vulnerability has been resolved: HID: elan: Fix potential double free in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails).
- https://git.kernel.org/stable/c/1af20714fedad238362571620be0bd690ded05b6
- https://git.kernel.org/stable/c/24f9dfdaece9bd75bb8dbfdba83eddeefdf7dc47
- https://git.kernel.org/stable/c/5291451851feeb66fd4bf0826710f482f3b1ab38
- https://git.kernel.org/stable/c/6d0726725c7c560495f5ff364862a2cefea542e3
- https://git.kernel.org/stable/c/8bb1716507ebf12d50bbf181764481de3b6bc7fd
- https://git.kernel.org/stable/c/c92ec22a991778a096342cf1a917ae36c5c86a90
- https://git.kernel.org/stable/c/f1d4f19a796551edc6679a681ea1756b8c578c08
Modified: 2025-10-01
CVE-2022-49514
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe Call of_node_put(platform_node) to avoid refcount leak in the error path.
- https://git.kernel.org/stable/c/0a1901f34f775b83ea4b8dbb5ed992147b9b8531
- https://git.kernel.org/stable/c/1e932aba3c7628c9f880ee9c2cfcc2ae3ba0c01e
- https://git.kernel.org/stable/c/23f340ed906c758cec6527376768e3bc1474ac30
- https://git.kernel.org/stable/c/48889eb3cce91d7f58e02bc07277b7f724b7a54a
- https://git.kernel.org/stable/c/4f4e0454e226de3bf4efd7e7924d1edc571c52d5
- https://git.kernel.org/stable/c/98d5afe868df998b0244f4c229ab758b4083684a
- https://git.kernel.org/stable/c/cc43b9fdca519c5b13be6a717bacbebccd628cf6
- https://git.kernel.org/stable/c/ebd5cb4f1f3f10b839e7575219e0f17b60c23113
- https://git.kernel.org/stable/c/fb66e0512e5ccc093070e21cf88cce8d98c181b5
Modified: 2025-10-01
CVE-2022-49517
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak.
- https://git.kernel.org/stable/c/05654431a18fe24e5e46a375d98904134628a102
- https://git.kernel.org/stable/c/318afb1442eeef089fe7f8a8297d97c0302ff6f6
- https://git.kernel.org/stable/c/61a85a20e8df5e0a92cfe169c92425c7bae0753b
- https://git.kernel.org/stable/c/9345122f5fb9f97a206f440f38bb656e53f46912
- https://git.kernel.org/stable/c/94587aa17abf8b26f543d2b29c44abc21bc36836
- https://git.kernel.org/stable/c/bc2afecaabd2a2c9f17e43b4793a30e3461bfb29
- https://git.kernel.org/stable/c/c71494f5f2b444adfd992a7359a0d2a791642b39
- https://git.kernel.org/stable/c/f279c49f17ce10866087ea6c0c57382158974b63
Modified: 2025-03-24
CVE-2022-49524
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: Fix the error handling in cx23885_initdev() When the driver fails to call the dma_set_mask(), the driver will get the following splat: [ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240 [ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590 [ 55.856822] Call Trace: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 This is because the driver has initialized the i2c related resources in cx23885_dev_setup() but not released them in error handling, fix this bug by modifying the error path that jumps after failing to call the dma_set_mask().
- https://git.kernel.org/stable/c/453514a874c78df1e7804e6e3aaa60c8d8deb6a8
- https://git.kernel.org/stable/c/6041d1a0365baa729b6adfb6ed5386d9388018db
- https://git.kernel.org/stable/c/7b9978e1c94e569d65a0e7e719abb9340f5db4a0
- https://git.kernel.org/stable/c/86bd6a579c6c60547706cabf299cd2c9feab3332
- https://git.kernel.org/stable/c/98106f100f50c487469903b9cf6d966785fc9cc3
- https://git.kernel.org/stable/c/ca17e7a532d1a55466cc007b3f4d319541a27493
- https://git.kernel.org/stable/c/e8123311cf06d7dae71e8c5fe78e0510d20cd30b
- https://git.kernel.org/stable/c/fa636e9ee4442215cd9a2e079cd5a8e1fe0cb8ba
Modified: 2025-10-21
CVE-2022-49525
In the Linux kernel, the following vulnerability has been resolved:
media: cx25821: Fix the warning when removing the module
When removing the module, we will get the following warning:
[ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]'
[ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0
[ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0
[ 14.759589] Call Trace:
[ 14.759792]
- https://git.kernel.org/stable/c/005fd553f5f10fe8618d92f94ad10f9051eac331
- https://git.kernel.org/stable/c/1f0fc1dfb5fdd456657519a97fab83691b96c6a0
- https://git.kernel.org/stable/c/2203436a4d24302871617373a7eb21bc17e38762
- https://git.kernel.org/stable/c/222292930c8ecc3516e03ec1f9fa8448be7ff496
- https://git.kernel.org/stable/c/258639bc55a586ee6df92d89786ccf1c71546d70
- https://git.kernel.org/stable/c/3f94169affa33c9db4a439d88f09cb2ed3a33332
- https://git.kernel.org/stable/c/4d6295b6d986476232332fffd08575b185f90d81
- https://git.kernel.org/stable/c/5beb85ff7d005ddb7bf604a4f2dc76f01b84b318
- https://git.kernel.org/stable/c/9d92291698e5cc35a2b8a1106a01ddd7d60ade2d
Modified: 2025-10-21
CVE-2022-49526
In the Linux kernel, the following vulnerability has been resolved: md/bitmap: don't set sb values if can't pass sanity check If bitmap area contains invalid data, kernel will crash then mdadm triggers "Segmentation fault". This is cluster-md speical bug. In non-clustered env, mdadm will handle broken metadata case. In clustered array, only kernel space handles bitmap slot info. But even this bug only happened in clustered env, current sanity check is wrong, the code should be changed. How to trigger: (faulty injection) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
- https://git.kernel.org/stable/c/0959aa00f9765bd8c654b1365012e41b51c733cc
- https://git.kernel.org/stable/c/27f672af28a8e9b783ff7f0eaf7ef2fbd5a2f4ba
- https://git.kernel.org/stable/c/422e8f7ba1e08c8e0e88d375bcb550bc2bbfe96d
- https://git.kernel.org/stable/c/cf9392282a2cf5a8d83dd1c5aa1a097e12f172bc
- https://git.kernel.org/stable/c/d8f1558e1daf54f53a90b4c5700ae3e3a4b13412
- https://git.kernel.org/stable/c/e68cb83a57a458b01c9739e2ad9cb70b04d1e6d2
- https://git.kernel.org/stable/c/e69e93120f6219b9cc4fba3b515b6ababd8548aa
Modified: 2025-10-01
CVE-2022-49527
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: avoid null dereference in deinit If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary.
- https://git.kernel.org/stable/c/0ac84ab50712879eac3c1dd2598440652a85d3d0
- https://git.kernel.org/stable/c/0ed5a643b1a4a46b9b7bfba5d468c10cc30e1359
- https://git.kernel.org/stable/c/2533acb652359c9e097dfa33587896af782e8a91
- https://git.kernel.org/stable/c/27ad46da44177a78a4a0cae6fe03906888c61aa1
- https://git.kernel.org/stable/c/86594f6af867b5165d2ba7b5a71fae3a5961e56c
- https://git.kernel.org/stable/c/9c385b961d4c378228e80f6abea8509cb67feab6
- https://git.kernel.org/stable/c/a21d15dde21d7e8ae047eb8368677407db45d840
- https://git.kernel.org/stable/c/b73ed0510bb8d9647cd8e8a4c4c8772bbe545c3a
Modified: 2025-10-01
CVE-2022-49530
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix double free in si_parse_power_table() In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated.
- https://git.kernel.org/stable/c/2615464854505188f909d0c07c37a6623693b5c7
- https://git.kernel.org/stable/c/43eb9b667b95f2a31c63e8949b0d2161b9be59c3
- https://git.kernel.org/stable/c/6c5bdaa1325be7f04b79ea992ab216739192d342
- https://git.kernel.org/stable/c/a5ce7051db044290b1a95045ff03c249005a3aa4
- https://git.kernel.org/stable/c/af832028af6f44c6c45645757079c4ed6884ade5
- https://git.kernel.org/stable/c/c0e811c4ccf3b42705976285e3a94cc82dea7300
- https://git.kernel.org/stable/c/ca1ce206894dd976275c78ee38dbc19873f22de9
- https://git.kernel.org/stable/c/f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd
- https://git.kernel.org/stable/c/fd2eff8b9dcbe469c3b7bbbc7083ab5ed94de07b
Modified: 2025-10-01
CVE-2022-49532
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218
- https://git.kernel.org/stable/c/0f8bc147a963686b7351aa35d1701124ffacac08
- https://git.kernel.org/stable/c/194d250cdc4a40ccbd179afd522a9e9846957402
- https://git.kernel.org/stable/c/32e10aabc287f09a148ff759bb9ce70b01b0012c
- https://git.kernel.org/stable/c/848dd072744ea662ab3097e3c8282bee552df218
- https://git.kernel.org/stable/c/c51d00472fa54b9b05c17789ed665c17adf3a25d
- https://git.kernel.org/stable/c/e0828456578cc8ba0a69147f7ae3428392eec287
- https://git.kernel.org/stable/c/edafcad84c4134ebec4bc24b29ca4497a1184eea
- https://git.kernel.org/stable/c/f85cb059fad03a3b33a50023be91e944bb065ae8
- https://git.kernel.org/stable/c/fadc626cae99aaa1325094edc6a9e2b883f3e562
Modified: 2025-10-01
CVE-2022-49538
In the Linux kernel, the following vulnerability has been resolved: ALSA: jack: Access input_dev under mutex It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock.
- https://git.kernel.org/stable/c/1b6a6fc5280e97559287b61eade2d4b363e836f2
- https://git.kernel.org/stable/c/582aea6084cc59fec881204f026816d1219f2348
- https://git.kernel.org/stable/c/5cc6f623f4818c7d7e9e966a45ebf324901ca9c5
- https://git.kernel.org/stable/c/74bab3bcf422593c582e47130aa8eb41ebb2dc09
- https://git.kernel.org/stable/c/8487a88136d54a1a4d3f26f1399685db648ab879
- https://git.kernel.org/stable/c/9e6a73b0c0f2014eb89249fb1640c5a3d58221c4
- https://git.kernel.org/stable/c/c093b62c40027c21d649c5534ad7aa3605a99b00
- https://git.kernel.org/stable/c/e2b8681769f6e205382f026b907d28aa5ec9d59a
- https://git.kernel.org/stable/c/f68bed124c7699e23ffb4ce4fcc84671e9193cde
Modified: 2025-10-01
CVE-2022-49544
In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference
- https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21
- https://git.kernel.org/stable/c/1ff6b0727c8988f25eeb670b6c038c1120bb58dd
- https://git.kernel.org/stable/c/48d4a820fd33f012e5f63735a59d15b5a3882882
- https://git.kernel.org/stable/c/528d2023ccf4748fd542582955236c1634a7d293
- https://git.kernel.org/stable/c/5f7ea274e88c0eeffe6bd6dbf6cf5c479d356af6
- https://git.kernel.org/stable/c/8fb1b9beb085bb767ae43e441db5ac6fcd66a04d
- https://git.kernel.org/stable/c/98d1dc32f890642476dbb78ed3437a456bf421b0
- https://git.kernel.org/stable/c/b4628e0d3754ab2fc98ee6e3d21851ba45798077
- https://git.kernel.org/stable/c/e8366bbabe1d207cf7c5b11ae50e223ae6fc278b
Modified: 2025-10-01
CVE-2022-49652
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() in to fix this.
- https://git.kernel.org/stable/c/37147e22cd8dfc0412495cb361708836157a4486
- https://git.kernel.org/stable/c/3bd66010398871807c1cebacee07d60ded1b1402
- https://git.kernel.org/stable/c/452b9dfd7aca96befce22634fadb111737f22bbe
- https://git.kernel.org/stable/c/61b4ef19c346dc21ab1d4f39f5c412e3037b2bdc
- https://git.kernel.org/stable/c/b31ab132561c7f1b6459039152b8d09e44eb3565
- https://git.kernel.org/stable/c/b5a817f8d62e9e13280928f3756e54854ae4962e
- https://git.kernel.org/stable/c/c132fe78ad7b4ce8b5d49a501a15c29d08eeb23a
- https://git.kernel.org/stable/c/cb9813d7eae917acd34436160a278b8b5d48ca53
Modified: 2025-10-01
CVE-2022-49656
In the Linux kernel, the following vulnerability has been resolved: ARM: meson: Fix refcount leak in meson_smp_prepare_cpus of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/2e1bcd33478ef44e63a45457055060b5fe4118ad
- https://git.kernel.org/stable/c/34d2cd3fccced12b958b8848e3eff0ee4296764c
- https://git.kernel.org/stable/c/3cf8ece9113242c10f83c7675ea4f4f67959ee43
- https://git.kernel.org/stable/c/3d90607e7e6afa89768b0aaa915b58bd2b849276
- https://git.kernel.org/stable/c/7208101ded1e9dcc52c8f0f8b16474211c871c1a
- https://git.kernel.org/stable/c/c5fbf4f74c94fd60d5e9bf9f7f8268c3601562ca
Modified: 2025-10-01
CVE-2022-49657
In the Linux kernel, the following vulnerability has been resolved: usbnet: fix memory leak in error case usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag v3: fix uninitialized buf pointer
- https://git.kernel.org/stable/c/0085da9df3dced730027923a6b48f58e9016af91
- https://git.kernel.org/stable/c/04894ab34faf40ab72a8a5ab5b404bb0606bbbff
- https://git.kernel.org/stable/c/3eed421ca5c809da93456f69203d164d5220be3d
- https://git.kernel.org/stable/c/5269209f54dd8dfd15f9383f3a3a1fe8370764f8
- https://git.kernel.org/stable/c/b55a21b764c1e182014630fa5486d717484ac58f
- https://git.kernel.org/stable/c/d5165e657987ff4ba0ace896d4376a3718a9fbc3
- https://git.kernel.org/stable/c/db89582ff330556188da856e01382ccbf3a5e706
- https://git.kernel.org/stable/c/e7b4f69946a38209b4a4f660bf0e4cbed94f9b4b
Modified: 2025-10-23
CVE-2022-49661
In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_open/close(): fix memory leak The gs_usb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usb_alloc_coherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usb_kill_anchored_urbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver. This commit is an adaptation of the techniques found in the esd_usb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usb_free_coherent(). Since the RX URBs were allocated in the gs_can_open(), we remove them in gs_can_close() rather than in the disconnect function as was done in esd_usb2. For more information, see the 928150fad41b ("can: esd_usb2: fix memory leak").
- https://git.kernel.org/stable/c/0e60230bc64355c80abe993d1719fdb318094e20
- https://git.kernel.org/stable/c/2bda24ef95c0311ab93bda00db40486acf30bd0a
- https://git.kernel.org/stable/c/339fa9f80d3b94177a7a459c6d115d3b56007d5a
- https://git.kernel.org/stable/c/6f655b5e13fa4b27e915b6c209ac0da74fd75963
- https://git.kernel.org/stable/c/c1d806bc29ff7ffe0e2a023583c8720ed96cb0b0
- https://git.kernel.org/stable/c/d0b8e223998866b3e7b2895927d4e9689b0a80d8
- https://git.kernel.org/stable/c/d91492638b054f4a359621ef216242be5973ed6b
- https://git.kernel.org/stable/c/ffb6cc6601ec7c8fa963dcf76025df4a02f2cf5c
Modified: 2025-03-24
CVE-2022-49667
In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [ 767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148] __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470
- https://git.kernel.org/stable/c/050133e1aa2cb49bb17be847d48a4431598ef562
- https://git.kernel.org/stable/c/2765749def4765c5052a4c66445cf4c96fcccdbc
- https://git.kernel.org/stable/c/63b2fe509f69b90168a75e04e14573dccf7984e6
- https://git.kernel.org/stable/c/893825289ba840afd86bfffcb6f7f363c73efff8
- https://git.kernel.org/stable/c/a853b7a3a9fd1d74a4ccdd9cd73512b7dace2f1e
- https://git.kernel.org/stable/c/b90ac60303063a43e17dd4aec159067599d255e6
- https://git.kernel.org/stable/c/ef0af7d08d26c5333ff4944a559279464edf6f15
- https://git.kernel.org/stable/c/f162f7c348fa2a5555bafdb5cc890b89b221e69c
Modified: 2025-10-24
CVE-2022-49672
In the Linux kernel, the following vulnerability has been resolved: net: tun: unlink NAPI from device on destruction Syzbot found a race between tun file and device destruction. NAPIs live in struct tun_file which can get destroyed before the netdev so we have to del them explicitly. The current code is missing deleting the NAPI if the queue was detached first.
- https://git.kernel.org/stable/c/3b9bc84d311104906d2b4995a9a02d7b7ddab2db
- https://git.kernel.org/stable/c/8145f77d38de4f88b8a69e1463f5c09ba189d77c
- https://git.kernel.org/stable/c/82e729aee59acefe135fceffadcbc5b86dd4f1b9
- https://git.kernel.org/stable/c/8661d4b8faa2f7ee7a559969c0a7c57f077b1728
- https://git.kernel.org/stable/c/a8cf919022373c97a84fe596bbea544f909c485d
- https://git.kernel.org/stable/c/bec1be0a745ab420718217e3e0d9542a75108989
Modified: 2025-10-24
CVE-2022-49673
In the Linux kernel, the following vulnerability has been resolved: dm raid: fix KASAN warning in raid5_add_disks There's a KASAN warning in raid5_add_disk when running the LVM testsuite. The warning happens in the test lvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warning by verifying that rdev->saved_raid_disk is within limits.
- https://git.kernel.org/stable/c/02cffb1921edadd9b6e4eee7ada4a5213e8ba12e
- https://git.kernel.org/stable/c/2d4e7c9898c20fb3d3f55381cab601761aab7d64
- https://git.kernel.org/stable/c/2fb2928728038280bd925ce2aafb4997e9d47ee9
- https://git.kernel.org/stable/c/3553a69bb52be2deba61d0ca064c41aee842bb35
- https://git.kernel.org/stable/c/617b365872a247480e9dcd50a32c8d1806b21861
- https://git.kernel.org/stable/c/d5b06039b195d4b6f94f5d345b1e4ac1975a9832
- https://git.kernel.org/stable/c/d8bca518d5272fe349e0a722fdb9e3acb661f3f0
- https://git.kernel.org/stable/c/f157bd9cf377a947fdb7035e69466b6ecdc17c17
Modified: 2025-10-24
CVE-2022-49674
In the Linux kernel, the following vulnerability has been resolved: dm raid: fix accesses beyond end of raid member array On dm-raid table load (using raid_ctr), dm-raid allocates an array rs->devs[rs->raid_disks] for the raid device members. rs->raid_disks is defined by the number of raid metadata and image tupples passed into the target's constructor. In the case of RAID layout changes being requested, that number can be different from the current number of members for existing raid sets as defined in their superblocks. Example RAID layout changes include: - raid1 legs being added/removed - raid4/5/6/10 number of stripes changed (stripe reshaping) - takeover to higher raid level (e.g. raid5 -> raid6) When accessing array members, rs->raid_disks must be used in control loops instead of the potentially larger value in rs->md.raid_disks. Otherwise it will cause memory access beyond the end of the rs->devs array. Fix this by changing code that is prone to out-of-bounds access. Also fix validate_raid_redundancy() to validate all devices that are added. Also, use braces to help clean up raid_iterate_devices(). The out-of-bounds memory accesses was discovered using KASAN. This commit was verified to pass all LVM2 RAID tests (with KASAN enabled).
- https://git.kernel.org/stable/c/332bd0778775d0cf105c4b9e03e460b590749916
- https://git.kernel.org/stable/c/5e161a8826b63c0b8b43e4a7fad1f956780f42ab
- https://git.kernel.org/stable/c/6352b2f4d8e95ec0ae576d7705435d64cfa29503
- https://git.kernel.org/stable/c/90de15357504c8097ab29769dc6852e16281e9e8
- https://git.kernel.org/stable/c/9bf2b0757b04c78dc5d6e3a198acca98457b32a1
- https://git.kernel.org/stable/c/bcff98500ea3b4e7615ec31d2bdd326bc1ef5134
- https://git.kernel.org/stable/c/df1a5ab0dd0775f2ea101c71f2addbc4c0ea0f85
Modified: 2025-10-01
CVE-2022-49677
In the Linux kernel, the following vulnerability has been resolved: ARM: cns3xxx: Fix refcount leak in cns3xxx_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/1ba904b6b16e08de5aed7c1349838d9cd0d178c5
- https://git.kernel.org/stable/c/45bebbc8cea7d586a6216dc62814bdb380b9b29b
- https://git.kernel.org/stable/c/68d4303bf59662b64bd555e2aa0518282d20aa4f
- https://git.kernel.org/stable/c/b8b84e01ca94e2e1f5492353e9c24dab520b2e5b
- https://git.kernel.org/stable/c/c980392af1473d6d5662f70d8089c8e6d85144a4
- https://git.kernel.org/stable/c/d1359e4129ad43e43972a28838b87291c51de23d
- https://git.kernel.org/stable/c/da3ee7cd2f15922ad88a7ca6deee2eafdc7cd214
- https://git.kernel.org/stable/c/dc5170aae24e04068fd5ea125d06c0ab51f48a27
Modified: 2025-10-01
CVE-2022-49678
In the Linux kernel, the following vulnerability has been resolved: soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. In brcmstb_init_sram, it pass dn to of_address_to_resource(), of_address_to_resource() will call of_find_device_by_node() to take reference, so we should release the reference returned by of_find_matching_node().
- https://git.kernel.org/stable/c/10ba9d499a9fd82ed40897e734ba19870a879407
- https://git.kernel.org/stable/c/30bbfeb480ae8b5ee43199d72417b232590440c2
- https://git.kernel.org/stable/c/37d838de369b07b596c19ff3662bf0293fdb09ee
- https://git.kernel.org/stable/c/4f5877bdf7b593e988f1924f4c3df6523f80b39c
- https://git.kernel.org/stable/c/734a4d15142bb4c8ecad2d8ec70d7564e78ae34d
- https://git.kernel.org/stable/c/dcafd5463d8f20c4f90ddc138a5738adb99f74c8
Modified: 2025-10-01
CVE-2022-49679
In the Linux kernel, the following vulnerability has been resolved: ARM: Fix refcount leak in axxia_boot_secondary of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/29ca9c4efacccdc15104a8d4bf10b5183fc92840
- https://git.kernel.org/stable/c/3c19fe3f04f4f4e7a2b722c2fd3c98356fc1d72b
- https://git.kernel.org/stable/c/44a5b3a073e5aaa5720929dba95b2725eb32bb65
- https://git.kernel.org/stable/c/4d9c60e868f7cf8e09956e7d5bb44d807d712699
- https://git.kernel.org/stable/c/71e12e5b02674459a24f16e965255d63b31fe049
- https://git.kernel.org/stable/c/7c7ff68daa93d8c4cdea482da4f2429c0398fcde
- https://git.kernel.org/stable/c/a9b76c232a1ce4cbf27862097f7eb634dcc779eb
- https://git.kernel.org/stable/c/b385cb59aac8d61c29bc72ebf3d19a536914af96
Modified: 2025-10-01
CVE-2022-49680
In the Linux kernel, the following vulnerability has been resolved: ARM: exynos: Fix refcount leak in exynos_map_pmu of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer.
- https://git.kernel.org/stable/c/31d09571bb071c20f6bdc0bb7ac1ef8dd2987c04
- https://git.kernel.org/stable/c/545ae5cbae839ce39bfe09828e413f1c916082de
- https://git.kernel.org/stable/c/68f28d52e6cbab8dcfa249cac4356d1d0573e868
- https://git.kernel.org/stable/c/7571bcecf01b69f0d3ec60ca41ce5d4c75411a4a
- https://git.kernel.org/stable/c/c4c79525042a4a7df96b73477feaf232fe44ae81
- https://git.kernel.org/stable/c/d23f76018e17618559da9eea179d137362023f95
- https://git.kernel.org/stable/c/f9b77a52937582a5b99a5a07e4ef1e2f48f87347
- https://git.kernel.org/stable/c/fc354856e9fad9cd36e2ad28f9da70716025055a
Modified: 2025-10-01
CVE-2022-49681
In the Linux kernel, the following vulnerability has been resolved: xtensa: xtfpga: Fix refcount leak bug in setup In machine_setup(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0162451723178602c37f0555d235dfa17e486112
- https://git.kernel.org/stable/c/0715d0e60052662c3f225342062f174dd721d1c7
- https://git.kernel.org/stable/c/173940b3ae40114d4179c251a98ee039dc9cd5b3
- https://git.kernel.org/stable/c/35d7e961be68732eb3acaeba81fb81ca16eafd05
- https://git.kernel.org/stable/c/6c0839cf1b9e1b3c88da6af76794583cbfae8da3
- https://git.kernel.org/stable/c/9b30c5c8884eda3f541229899671cebbad15979b
- https://git.kernel.org/stable/c/a52972ee706b438302eb0350e61f378eb191e3d1
- https://git.kernel.org/stable/c/b12d5c52f073a0420622aaf2f21b615cce8b36cc
Modified: 2025-10-01
CVE-2022-49682
In the Linux kernel, the following vulnerability has been resolved: xtensa: Fix refcount leak bug in time.c In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.
- https://git.kernel.org/stable/c/0dcc1dd8a5dd9240639f1051dfaa2dffc9fbbde5
- https://git.kernel.org/stable/c/0e403a383c14b63c86bd9df085b7e573e9caee64
- https://git.kernel.org/stable/c/3e5eb904d9ba657308fc75a5de434b0e58dcb8d7
- https://git.kernel.org/stable/c/7de4502af68f4f3932f450157f5483eb7b33cb74
- https://git.kernel.org/stable/c/a0117dc956429f2ede17b323046e1968d1849150
- https://git.kernel.org/stable/c/af0ff2da01521144bc11194f4c26485d7c9cee73
- https://git.kernel.org/stable/c/e5234a9d64a976abd134a14710dcd5188158a7c5
- https://git.kernel.org/stable/c/f1eaf4ba5372ad111f687a80c67e270708e14c23
Modified: 2025-03-24
CVE-2022-49685
In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix use-after-free on remove Ensure that the irq_work has completed before the trigger is freed. ================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25 Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write ==================================================================
- https://git.kernel.org/stable/c/31ff3309b47d98313c61b8301bf595820cc3cc33
- https://git.kernel.org/stable/c/4687c3f955240ca2a576bdc3f742d4d915b6272d
- https://git.kernel.org/stable/c/4ef1e521be610b720daeb7cf899fedc7db0274c4
- https://git.kernel.org/stable/c/5e39397d60dacc7f5d81d442c1c958eaaaf31128
- https://git.kernel.org/stable/c/78601726d4a59a291acc5a52da1d3a0a6831e4e8
- https://git.kernel.org/stable/c/b07a30a774b3c3e584a68dc91779c68ea2da4813
- https://git.kernel.org/stable/c/d6111e7bdb8ec27eb43d01c4cd4ff1620a75f7f2
- https://git.kernel.org/stable/c/fd5d8fb298a2866c337da635c79d63c3afabcaf7
Modified: 2026-01-22
CVE-2022-49687
In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix xdp_rxq_info bug after suspend/resume
The following sequence currently causes a driver bug warning
when using virtio_net:
# ip link set eth0 up
# echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem)
- https://git.kernel.org/stable/c/340fbdc8011f2dc678f622c5ce1cbb5ab8305de7
- https://git.kernel.org/stable/c/57ee40f1b198b59d43c216fbc4672f9300d3c8b0
- https://git.kernel.org/stable/c/8af52fe9fd3bf5e7478da99193c0632276e1dfce
- https://git.kernel.org/stable/c/8c7a32b7c15555beddc5810c3334d9cefff061bf
- https://git.kernel.org/stable/c/8d7fe9ad6fddc2af8bde4b921b4f8fab231ed38c
- https://git.kernel.org/stable/c/9222672fa6370f0ec3d899662cb8680e9282fc4c
Modified: 2025-10-24
CVE-2022-49688
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix dynamic root getattr
The recent patch to make afs_getattr consult the server didn't account
for the pseudo-inodes employed by the dynamic root-type afs superblock
not having a volume or a server to access, and thus an oops occurs if
such a directory is stat'd.
Fix this by checking to see if the vnode->volume pointer actually points
anywhere before following it in afs_getattr().
This can be tested by stat'ing a directory in /afs. It may be
sufficient just to do "ls /afs" and the oops looks something like:
BUG: kernel NULL pointer dereference, address: 0000000000000020
...
RIP: 0010:afs_getattr+0x8b/0x14b
...
Call Trace:
- https://git.kernel.org/stable/c/2b2bba96526f25f2eba74ecadb031de2e05a83ce
- https://git.kernel.org/stable/c/65c24caf1b9f5b08397c6e805ec24ebc390c6e4d
- https://git.kernel.org/stable/c/7844ceada44eca740d31beb3d97b8511b1ca0a9b
- https://git.kernel.org/stable/c/7b564e3254b7db5fbfbf11a824627a6c31b932b4
- https://git.kernel.org/stable/c/cb78d1b5efffe4cf97e16766329dd7358aed3deb
- https://git.kernel.org/stable/c/e3a232e5767051483ffad4cef7d0a89d292a192b
Modified: 2025-10-24
CVE-2022-49691
In the Linux kernel, the following vulnerability has been resolved:
erspan: do not assume transport header is always set
Rewrite tests in ip6erspan_tunnel_xmit() and
erspan_fb_xmit() to not assume transport header is set.
syzbot reported:
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]
WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Modules linked in:
CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]
RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963
Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00
RSP: 0018:ffffc90005daf910 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000
RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003
RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40
R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000
FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0
Call Trace:
- https://git.kernel.org/stable/c/02da602bc2f353dccd9e489a604490034ded941e
- https://git.kernel.org/stable/c/2c8aeffc7c586d53e1d380f010bdca4f710f2480
- https://git.kernel.org/stable/c/301bd140ed0b24f0da660874c7e8a47dad8c8222
- https://git.kernel.org/stable/c/a3b2470399f679587c45abe56e551caf10becca2
- https://git.kernel.org/stable/c/cec9867ee55478ef5dcb2adf030fe0c442a4c4ee
- https://git.kernel.org/stable/c/fb401f37f6eadf24956d93687e5758c163c0d12b
Modified: 2025-03-25
CVE-2022-49700
In the Linux kernel, the following vulnerability has been resolved: mm/slub: add missing TID updates on slab deactivation The fastpath in slab_alloc_node() assumes that c->slab is stable as long as the TID stays the same. However, two places in __slab_alloc() currently don't update the TID when deactivating the CPU slab. If multiple operations race the right way, this could lead to an object getting lost; or, in an even more unlikely situation, it could even lead to an object being freed onto the wrong slab's freelist, messing up the `inuse` counter and eventually causing a page to be freed to the page allocator while it still contains slab objects. (I haven't actually tested these cases though, this is just based on looking at the code. Writing testcases for this stuff seems like it'd be a pain...) The race leading to state inconsistency is (all operations on the same CPU and kmem_cache): - task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu_ptr() (enables preemption) - [PREEMPT B->A] - task A: finish do_slab_free(): - this_cpu_cmpxchg_double() succeeds() - [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL] From there, the object on c->freelist will get lost if task B is allowed to continue from here: It will proceed to the retry_load_slab label, set c->slab, then jump to load_freelist, which clobbers c->freelist. But if we instead continue as follows, we get worse corruption: - task A: run __slab_free() on object from other struct slab: - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial) - task A: run slab_alloc_node() with NUMA node constraint: - fastpath fails (c->slab is NULL) - call __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - c->slab is NULL: goto new_slab - slub_percpu_partial() is non-NULL - set c->slab to slub_percpu_partial(c) - [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects from slab-2] - goto redo - node_match() fails - goto deactivate_slab - existing c->freelist is passed into deactivate_slab() - inuse count of slab-1 is decremented to account for object from slab-2 At this point, the inuse count of slab-1 is 1 lower than it should be. This means that if we free all allocated objects in slab-1 except for one, SLUB will think that slab-1 is completely unused, and may free its page, leading to use-after-free.
- https://git.kernel.org/stable/c/0515cc9b6b24877f59b222ade704bfaa42caa2a6
- https://git.kernel.org/stable/c/197e257da473c725dfe47759c3ee02f2398d8ea5
- https://git.kernel.org/stable/c/308c6d0e1f200fd26c71270c6e6bfcf0fc6ff082
- https://git.kernel.org/stable/c/6c32496964da0dc230cea763a0e934b2e02dabd5
- https://git.kernel.org/stable/c/d6a597450e686d4c6388bd3cdcb17224b4dae7f0
- https://git.kernel.org/stable/c/e2b2f0e2e34d71ae6c2a1114fd3c525930e84bc7
- https://git.kernel.org/stable/c/e7e3e90d671078455a3a08189f89d85b3da2de9e
- https://git.kernel.org/stable/c/eeaa345e128515135ccb864c04482180c08e3259
Modified: 2025-10-01
CVE-2022-49707
In the Linux kernel, the following vulnerability has been resolved:
ext4: add reserved GDT blocks check
We capture a NULL pointer issue when resizing a corrupt ext4 image which
is freshly clear resize_inode feature (not run e2fsck). It could be
simply reproduced by following steps. The problem is because of the
resize_inode feature was cleared, and it will convert the filesystem to
meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
not reduced to zero, so could we mistakenly call reserve_backup_gdb()
and passing an uninitialized resize_inode to it when adding new group
descriptors.
mkfs.ext4 /dev/sda 3G
tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
mount /dev/sda /mnt
resize2fs /dev/sda 8G
========
BUG: kernel NULL pointer dereference, address: 0000000000000028
CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
...
RIP: 0010:ext4_flex_group_add+0xe08/0x2570
...
Call Trace:
- https://git.kernel.org/stable/c/0dc2fca8e4f9ac4a40e8424a10163369cca0cc06
- https://git.kernel.org/stable/c/33b1bba31f4c784d33d2c2517964bdccdc9204cd
- https://git.kernel.org/stable/c/7c921328ac760bba780bdace41f4cd045f7f1405
- https://git.kernel.org/stable/c/af75c481a2e45e70f62f5942c93695e95bf7bd21
- https://git.kernel.org/stable/c/b55c3cd102a6f48b90e61c44f7f3dda8c290c694
- https://git.kernel.org/stable/c/b9747263b13e5290ac4d63bec47e38f701303cad
- https://git.kernel.org/stable/c/bfd004a1d3a062aac300523d406ac1f3e5f1a82c
- https://git.kernel.org/stable/c/fba54289176702a7caac0b64738406775817f451
Modified: 2025-10-24
CVE-2022-49708
In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on ext4_mb_use_inode_pa Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/mballoc.c:3211! [...] RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f [...] Call Trace: ext4_mb_new_blocks+0x9df/0x5d30 ext4_ext_map_blocks+0x1803/0x4d80 ext4_map_blocks+0x3a4/0x1a10 ext4_writepages+0x126d/0x2c30 do_writepages+0x7f/0x1b0 __filemap_fdatawrite_range+0x285/0x3b0 file_write_and_wait_range+0xb1/0x140 ext4_sync_file+0x1aa/0xca0 vfs_fsync_range+0xfb/0x260 do_fsync+0x48/0xa0 [...] ================================================================== Above issue may happen as follows: ------------------------------------- do_fsync vfs_fsync_range ext4_sync_file file_write_and_wait_range __filemap_fdatawrite_range do_writepages ext4_writepages mpage_map_and_submit_extent mpage_map_one_extent ext4_map_blocks ext4_mb_new_blocks ext4_mb_normalize_request >>> start + size <= ac->ac_o_ex.fe_logical ext4_mb_regular_allocator ext4_mb_simple_scan_group ext4_mb_use_best_found ext4_mb_new_preallocation ext4_mb_new_inode_pa ext4_mb_use_inode_pa >>> set ac->ac_b_ex.fe_len <= 0 ext4_mb_mark_diskspace_used >>> BUG_ON(ac->ac_b_ex.fe_len <= 0); we can easily reproduce this problem with the following commands: `fallocate -l100M disk` `mkfs.ext4 -b 1024 -g 256 disk` `mount disk /mnt` `fsstress -d /mnt -l 0 -n 1000 -p 1` The size must be smaller than or equal to EXT4_BLOCKS_PER_GROUP. Therefore, "start + size <= ac->ac_o_ex.fe_logical" may occur when the size is truncated. So start should be the start position of the group where ac_o_ex.fe_logical is located after alignment. In addition, when the value of fe_logical or EXT4_BLOCKS_PER_GROUP is very large, the value calculated by start_off is more accurate.
- https://git.kernel.org/stable/c/5707d721d1819db57dba57b1d4623034fcb32047
- https://git.kernel.org/stable/c/6880fb2e64331b9fdc85d3f32b1d7e81ad8703f1
- https://git.kernel.org/stable/c/6fdaf31ad5f3d3afab744dfd9a8b0d9142aa881f
- https://git.kernel.org/stable/c/887a3e9ad4b8309a2266bce7ae749b2bf1f7a687
- https://git.kernel.org/stable/c/90f0f9d45dff0128c0fca0d2358c4153b024afa6
- https://git.kernel.org/stable/c/a08f789d2ab5242c07e716baf9a835725046be89
- https://git.kernel.org/stable/c/a37c1359714da42517dd19d36fc3c4d17edba832
- https://git.kernel.org/stable/c/a6b31616e5afe1d3972cb0682a373e50597faf5c
Modified: 2025-10-01
CVE-2022-49712
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer.
- https://git.kernel.org/stable/c/0ef6917c0524da5b88496b9706628ffef108b9bb
- https://git.kernel.org/stable/c/2a598da14856ead80c726b38ba426c68637d9211
- https://git.kernel.org/stable/c/46da1e4a8b6329479433b2a4056941dfdd7f3efd
- https://git.kernel.org/stable/c/4757c9ade34178b351580133771f510b5ffcf9c8
- https://git.kernel.org/stable/c/57901c658f77d9ea2e772f35cb38e47efb54c558
- https://git.kernel.org/stable/c/727c82d003e0ec64411fd1257a9a57de4ad7a99a
- https://git.kernel.org/stable/c/b75bddfcc18170ce8e3fb695a76ec2dec4ce0ea5
- https://git.kernel.org/stable/c/d85e4e6284a91aa2d1ab004e9d84b9c09b4aa203
Modified: 2025-10-01
CVE-2022-49713
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: Fix memory leak in dwc2_hcd_init usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when platform_get_resource() fails to prevent memory leak. goto error2 label instead error1 to fix this.
- https://git.kernel.org/stable/c/3755278f078460b021cd0384562977bf2039a57a
- https://git.kernel.org/stable/c/52bfcedbfd5bf962dbdcb6e761f4d0dd3ba26dfd
- https://git.kernel.org/stable/c/6506aff2dc2f7059aa3d45ee2e8639b25e87090f
- https://git.kernel.org/stable/c/701d8ec01e0f229d4db6f43d3d64ee479120cbeb
- https://git.kernel.org/stable/c/84e6d0af87e27bbc0db94f2e7323b34abe17b6e5
- https://git.kernel.org/stable/c/981ee40649e5fd9550f82db1fbb3bfab037da346
- https://git.kernel.org/stable/c/a44a8a762f7fe9ad3c065813d058e835a6180cb2
Modified: 2025-10-01
CVE-2022-49715
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/506a88a5bf261d76a5214c0338a320f2214c67ac
- https://git.kernel.org/stable/c/8d884c08eeb83142a7173cb46bcff0434ec42cf1
- https://git.kernel.org/stable/c/c136c2924a59a399aa789858cfb320d481964fb7
- https://git.kernel.org/stable/c/cc5984cf270b69d03f9f4b27063e535036c659e9
- https://git.kernel.org/stable/c/e824482e2c5edacc961b7dd30a92fd47606c3036
- https://git.kernel.org/stable/c/fa1ad9d4cc47ca2470cd904ad4519f05d7e43a2b
Modified: 2025-10-01
CVE-2022-49719
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic/realview: Fix refcount leak in realview_gic_of_init of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/16b603cb8d34c2d917983918db1f88c8b831baaa
- https://git.kernel.org/stable/c/486f68f85085d9b16ae097679b1486dcb1b6eb69
- https://git.kernel.org/stable/c/56526c3883fc7a1f5898b1d40a02c8b8685a5d92
- https://git.kernel.org/stable/c/5d38720661a4b9c87705c206a6081177ffb8ec1d
- https://git.kernel.org/stable/c/87da903ce632d5689bef66d56ee5dae700d82104
- https://git.kernel.org/stable/c/b634af84bc1edece4e63317b0ad95618dd3a8693
- https://git.kernel.org/stable/c/e52a58b79f11755ea7e877015c4a1704303fa55f
- https://git.kernel.org/stable/c/f4b98e314888cc51486421bcf6d52852452ea48b
Modified: 2025-10-24
CVE-2022-49724
In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Fix free_irq() on remove Pass the correct dev_id to free_irq() to fix this splat when the driver is unbound: WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq Trying to free already-free IRQ 65 Call Trace: warn_slowpath_fmt free_irq goldfish_tty_remove platform_remove device_remove device_release_driver_internal device_driver_detach unbind_store drv_attr_store ...
- https://git.kernel.org/stable/c/499e13aac6c762e1e828172b0f0f5275651d6512
- https://git.kernel.org/stable/c/65ca4db68b6819244df9024aea4be55edf8af1ef
- https://git.kernel.org/stable/c/a6fcd7ffd76a9c1d998a2d02d518c78a55c5bed8
- https://git.kernel.org/stable/c/c4b0b8edccb0cfb15a8cecf4161e0571d3daac64
- https://git.kernel.org/stable/c/c83a1d40dc624070a203eb383ef9fb60eb634136
- https://git.kernel.org/stable/c/f7183c76d500324b8b5bd0af5e663cfa57b7b836
- https://git.kernel.org/stable/c/fb15e79cacddfbc62264e6e807bde50ad688e988
Modified: 2025-10-24
CVE-2022-49725
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix call trace in setup_tx_descriptors After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors. Problem was that pf reset calls i40e_vsi_close in prep_for_reset and ethtool -t calls i40e_vsi_close in diag_test. If there was not enough time between those commands the second i40e_vsi_close starts before previous i40e_vsi_close was done which leads to crash. Add check to diag_test if pf is in reset and don't start offline tests if it is true. Add netif_info("testing failed") into unhappy path of i40e_diag_test()
- https://git.kernel.org/stable/c/0a4e5a3dc5e41212870e6043895ae02455c93f63
- https://git.kernel.org/stable/c/15950157e2c24865b696db1c9ccc72743ae0e967
- https://git.kernel.org/stable/c/322271351b0e41565171e4cce70ea41854fac115
- https://git.kernel.org/stable/c/5ba9956ca57e361fb13ea369bb753eb33177acc7
- https://git.kernel.org/stable/c/814092927a215f5ca6c08249ec72a205e0b473cd
- https://git.kernel.org/stable/c/fd5855e6b1358e816710afee68a1d2bc685176ca
- https://git.kernel.org/stable/c/ff6e03fe84bc917bb0c907d02de668c2fe101712
Modified: 2025-10-01
CVE-2022-49727
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max.
- https://git.kernel.org/stable/c/034246122f5c5e2e2a0b9fe04e24517920e9beb1
- https://git.kernel.org/stable/c/0e818d433fc2718fe4da044ffca7431812a7e04e
- https://git.kernel.org/stable/c/27a37755ceb401111ded76810359d3adc4b268a1
- https://git.kernel.org/stable/c/2cf73c7cb6125083408d77f43d0e84d86aed0000
- https://git.kernel.org/stable/c/2f42389d270f2304c8855b0b63498a5a4d0c053d
- https://git.kernel.org/stable/c/6c4e3486d21173d60925ef52e512cae727b43d30
- https://git.kernel.org/stable/c/b8879ca1fd7348b4d5db7db86dcb97f60c73d751
- https://git.kernel.org/stable/c/f638a84afef3dfe10554c51820c16e39a278c915
Modified: 2025-10-01
CVE-2022-49729
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well. Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak. Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.
- https://git.kernel.org/stable/c/0eeec1a8b0cd38c47edeb042980a6aeacecf35ed
- https://git.kernel.org/stable/c/1eb0afecfb9cd0f38424b82bd9aaa542310934ee
- https://git.kernel.org/stable/c/3e7c7df6991ac349f2fa8540047757df666e610f
- https://git.kernel.org/stable/c/3eadc560c1919b8193d17334145dad9a917960e4
- https://git.kernel.org/stable/c/6616872cfe7f0474a22dd1f12699f95bcf81a54d
- https://git.kernel.org/stable/c/6b4d8b44e7163a77fe942f5b80e1651c1b78c537
- https://git.kernel.org/stable/c/8a4d480702b71184fabcf379b80bf7539716752e
- https://git.kernel.org/stable/c/f21f908347712b8288ffe83b531b5e977042b29c
Modified: 2025-10-01
CVE-2022-49731
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/07cbdb4807d369fbda73062a91b570c4dc5ec429
- https://git.kernel.org/stable/c/1ac5efee33f29e704226506d429b84575a5d66f8
- https://git.kernel.org/stable/c/253334f84c81bc6a43af489f108c0bddad989eef
- https://git.kernel.org/stable/c/36cd19e7d4e5571d77a2ed20c5b6ef50cf57734a
- https://git.kernel.org/stable/c/a810bd5af06977a847d1f202b22d7defd5c62497
- https://git.kernel.org/stable/c/bf476fe22aa1851bab4728e0c49025a6a0bea307
- https://git.kernel.org/stable/c/ca4693e6e06e4fd2b240c0fec47aa2498c94848e
- https://git.kernel.org/stable/c/ff128fbea720bf763fa345680dda5f050bc24a47
Modified: 2023-07-08
GHSA-j4rf-7357-f4cg
Unpatched extfs vulnerabilities are exploitable through suid-mode Apptainer
- https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
- https://nvd.nist.gov/vuln/detail/CVE-2022-1184
- https://nvd.nist.gov/vuln/detail/CVE-2023-30549
- https://github.com/apptainer/apptainer/commit/5a4964f5ba9c8d89a0e353b97f51fd607670a9f7
- https://github.com/torvalds/linux/commit/2220eaf90992c11d888fe771055d4de3303
- https://github.com/torvalds/linux/commit/4f04351888a83e595571de672e0a4a8b74f
- https://github.com/torvalds/linux/commit/61a1d87a324ad5e3ed27c6699dfc93218fcf3201
- https://github.com/torvalds/linux/commit/65f8ea4cd57dbd46ea13b41dc8bac03176b04233
- https://www.suse.com/security/cve/CVE-2022-1184.html
- https://ubuntu.com/security/CVE-2022-1184
- https://sylabs.io/2023/04/response-to-cve-2023-30549
- https://security.gentoo.org/glsa/202311-13
- https://security-tracker.debian.org/tracker/CVE-2022-1184
- https://lwn.net/Articles/932137
- https://lwn.net/Articles/932136
- https://github.com/apptainer/apptainer/releases/tag/v1.1.8
- https://github.com/apptainer/apptainer
- https://access.redhat.com/security/cve/cve-2022-1184
