ALT-BU-2022-6846-16
Branch c9f2 update bulletin.
Package libvncserver updated to version 0.9.13-alt3 for branch c9f2 in task 309027.
Closed vulnerabilities
Modified: 2024-11-21
CVE-2020-29260
libvncclient v0.9.13 was discovered to contain a memory leak via the function rfbClientCleanup().
- https://github.com/LibVNC/libvncserver/commit/bef41f6ec4097a8ee094f90a1b34a708fbd757ec
- https://lists.debian.org/debian-lts-announce/2022/09/msg00035.html
- https://github.com/LibVNC/libvncserver/commit/bef41f6ec4097a8ee094f90a1b34a708fbd757ec
- https://lists.debian.org/debian-lts-announce/2022/09/msg00035.html
Package kernel-image-std-def updated to version 5.10.150-alt0.c9f.2 for branch c9f2 in task 309036.
Closed vulnerabilities
Modified: 2025-01-29
BDU:2022-06272
Уязвимость функции cfg80211_update_notlisted_nontrans файла net/wireless/scan.c ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2022-06273
Уязвимость функционала подсчета ссылок в режиме BSS (Basic Service Set) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2022-06274
Уязвимость ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-06620
Уязвимость функции del_timer компонента drivers/isdn/mISDN/l1oip_core.c ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-07349
Уязвимость драйвера drivers/usb/mon/mon_bin.c ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2023-00631
Уязвимость функции nilfs_new_inode компонента BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-07631
Уязвимость драйвера файловой системы NILFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-11-18
BDU:2024-04235
Уязвимость функции amu_fie_setup() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-10-10
BDU:2024-06284
Уязвимость функции kmalloc() в компоненте mm/slub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06320
Уязвимость функции of_xudma_dev_get() в компоненте dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06335
Уязвимость функции request_threaded_irq() в компоненте gpiolib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-10
BDU:2024-06336
Уязвимость компонента ipvlan ядра операционной системы Linux, позволяющая нарушителю оказывать воздействие на целостность и доступность системы
Modified: 2024-10-10
BDU:2024-06337
Уязвимость функции nf_osf_find() в компоненте netfilter ядра операционной системы Linux, позволяющая нарушителю оказывать воздействие на конфиденциальность системы
Modified: 2026-01-20
BDU:2024-08405
Уязвимость компонента inet ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-02-25
BDU:2024-09391
Уязвимость компонента gpio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09392
Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-09918
Уязвимость компонентов s390/dasd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10013
Уязвимость компонента sfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10014
Уязвимость компонента sfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10016
Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10017
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10018
Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10019
Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-24
BDU:2024-10021
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации
Modified: 2025-02-24
BDU:2024-10025
Уязвимость компонентов drm/gma500 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2024-10026
Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12804
Уязвимость модуля fs/nilfs2/segment.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12810
Уязвимость функции ext4_fc_record_regions() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-12812
Уязвимость функции rtw_init_cmd_priv() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-14249
Уязвимость функции __ext4_ext_check() модуля fs/ext4/extents.c поддержки файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01283
Уязвимость функции btrfs_quota_enable() модуля fs/btrfs/qgroup.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01343
Уязвимость функции l2cap_connect_create_rsp() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01631
Уязвимость функции nouveau_gem_prime_import_sg_table() модуля drivers/gpu/drm/nouveau/nouveau_prime.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02173
Уязвимость функции nfsd4_close_open_stateid() в модуле fs/nfsd/nfs4state.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02179
Уязвимость функции jbd2_fc_wait_bufs() в модуле fs/jbd2/journal.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02180
Уязвимость функции inode_init_always() в модуле fs/inode.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02181
Уязвимость функции brcmf_netdev_start_xmit() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02259
Уязвимость функции rapl_compute_time_window_core() в модуле drivers/powercap/intel_rapl_common.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02280
Уязвимость функции jsm_probe_one() модуля drivers/tty/serial/jsm/jsm_driver.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02339
Уязвимость функции sk_stream_wait_memory() в модуле net/core/stream.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02367
Уязвимость функции nbd_start_device_ioctl() в модуле drivers/block/nbd.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02433
Уязвимость функции ge_b850v3_lvds_remove() модуля drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02436
Уязвимость функции lpuart_dma_shutdown() модуля drivers/tty/serial/fsl_lpuart.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02441
Уязвимость функции hci_conn_add_sysfs() модуля net/bluetooth/hci_sysfs.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03265
Уязвимость функции snd_pcm_oss_sync() модуля sound/core/oss/pcm_oss.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03771
Уязвимость функции bridge_platform_create() модуля arch/mips/sgi-ip27/ip27-xtalk.c поддержки архитектуры MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03774
Уязвимость функции __cld_pipe_inprogress_downcall() модуля fs/nfsd/nfs4recover.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03843
Уязвимость функции pl353_smc_probe() модуля drivers/memory/pl353-smc.c драйвера контроллера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04059
Уязвимость функции tegra210_clock_init() модуля drivers/clk/tegra/clk-tegra210.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04060
Уязвимость функции tegra20_clock_init() модуля drivers/clk/tegra/clk-tegra20.c драйвера контроллера тактовой частоты Samsung Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04086
Уязвимость функции mipi_dsi_remove_device_fn() модуля drivers/gpu/drm/drm_mipi_dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04409
Уязвимость функции smp_execute_task_sg() модуля drivers/scsi/libsas/sas_expander.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04513
Уязвимость функции gbaudio_dapm_free_controls() модуля drivers/staging/greybus/audio_helper.c драйвера устройств линейки Greybus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04858
Уязвимость функции xhci_alloc_stream_info() модуля drivers/usb/host/xhci-mem.c драйвера устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04862
Уязвимость функции show_cpuinfo() модуля arch/um/kernel/um_arch.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04864
Уязвимость функции ext4_write_info() модуля fs/ext4/super.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04868
Уязвимость функции buffer_prepare() модуля drivers/media/pci/cx88/cx88-video.c драйвера мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05856
Уязвимость функции percpu_init_rwsem() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05858
Уязвимость функции of_lpddr3_get_ddr_timings() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05862
Уязвимость функции getpeername() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05950
Уязвимость функции unix_gc() модуля fnet/unix/garbage.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05952
Уязвимость функции of_get_ddr_timings() модуля drivers/memory/of_memory.c драйвера контроллера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05956
Уязвимость функций vhost_vsock_alloc_pkt() (drivers/vhost/vsock.c) и virtio_transport_free_pkt() (net/vmw_vsock/virtio_transport_common.c) драйвера общей реализации IOTLB для vhost и vringh ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06079
Уязвимость функции dump_zones() в модуле drivers/md/raid0.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06083
Уязвимость функции ext4_dio_write_iter() в модуле fs/ext4/file.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-14
CVE-2021-47103
In the Linux kernel, the following vulnerability has been resolved:
inet: fully convert sk->sk_rx_dst to RCU rules
syzbot reported various issues around early demux,
one being included in this changelog [1]
sk->sk_rx_dst is using RCU protection without clearly
documenting it.
And following sequences in tcp_v4_do_rcv()/tcp_v6_do_rcv()
are not following standard RCU rules.
[a] dst_release(dst);
[b] sk->sk_rx_dst = NULL;
They look wrong because a delete operation of RCU protected
pointer is supposed to clear the pointer before
the call_rcu()/synchronize_rcu() guarding actual memory freeing.
In some cases indeed, dst could be freed before [b] is done.
We could cheat by clearing sk_rx_dst before calling
dst_release(), but this seems the right time to stick
to standard RCU annotations and debugging facilities.
[1]
BUG: KASAN: use-after-free in dst_check include/net/dst.h:470 [inline]
BUG: KASAN: use-after-free in tcp_v4_early_demux+0x95b/0x960 net/ipv4/tcp_ipv4.c:1792
Read of size 2 at addr ffff88807f1cb73a by task syz-executor.5/9204
CPU: 0 PID: 9204 Comm: syz-executor.5 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
- https://git.kernel.org/stable/c/0249a4b8a554f2eb6a27b62516fa50168584faa4
- https://git.kernel.org/stable/c/68c34ce11ef23328692aa35fa6aaafdd75913100
- https://git.kernel.org/stable/c/75a578000ae5e511e5d0e8433c94a14d9c99c412
- https://git.kernel.org/stable/c/8f905c0e7354ef261360fb7535ea079b1082c105
- https://git.kernel.org/stable/c/92e6e36ecd16808866ac6172b9491b5097cde449
- https://git.kernel.org/stable/c/c3bb4a7e8cbc984e1cdac0fe6af60e880214ed6e
- https://git.kernel.org/stable/c/f039b43cbaea5e0700980c2f0052da05a70782e0
- https://git.kernel.org/stable/c/0249a4b8a554f2eb6a27b62516fa50168584faa4
- https://git.kernel.org/stable/c/68c34ce11ef23328692aa35fa6aaafdd75913100
- https://git.kernel.org/stable/c/75a578000ae5e511e5d0e8433c94a14d9c99c412
- https://git.kernel.org/stable/c/8f905c0e7354ef261360fb7535ea079b1082c105
- https://git.kernel.org/stable/c/92e6e36ecd16808866ac6172b9491b5097cde449
- https://git.kernel.org/stable/c/c3bb4a7e8cbc984e1cdac0fe6af60e880214ed6e
- https://git.kernel.org/stable/c/f039b43cbaea5e0700980c2f0052da05a70782e0
Modified: 2024-11-21
CVE-2022-2978
A flaw use after free in the Linux kernel NILFS file system was found in the way user triggers function security_inode_alloc to fail with following call to function nilfs_mdt_destroy. A local user could use this flaw to crash the system or potentially escalate their privileges on the system.
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91%40hust.edu.cn/T/#u
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91%40hust.edu.cn/T/#u
Modified: 2024-11-21
CVE-2022-3565
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function del_timer of the file drivers/isdn/mISDN/l1oip_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211088.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211088
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://vuldb.com/?id.211088
Modified: 2024-11-21
CVE-2022-3649
A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is the function nilfs_new_inode of the file fs/nilfs2/inode.c of the component BPF. The manipulation leads to use after free. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211992.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20230214-0009/
- https://vuldb.com/?id.211992
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20230214-0009/
- https://vuldb.com/?id.211992
Modified: 2025-05-15
CVE-2022-41674
An issue was discovered in the Linux kernel before 5.19.16. Attackers able to inject WLAN frames could cause a buffer overflow in the ieee80211_bss_info_update function in net/mac80211/scan.c.
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- https://bugzilla.suse.com/show_bug.cgi?id=1203770
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://www.debian.org/security/2022/dsa-5257
- https://www.openwall.com/lists/oss-security/2022/10/13/5
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- https://bugzilla.suse.com/show_bug.cgi?id=1203770
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://www.debian.org/security/2022/dsa-5257
- https://www.openwall.com/lists/oss-security/2022/10/13/5
Modified: 2025-05-15
CVE-2022-42719
A use-after-free in the mac80211 stack when parsing a multi-BSSID element in the Linux kernel 5.2 through 5.19.x before 5.19.16 could be used by attackers (able to inject WLAN frames) to crash the kernel and potentially execute code.
- http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204051
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
- http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/2
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204051
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-05-15
CVE-2022-42720
Various refcounting bugs in the multi-BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.x before 5.19.16 could be used by local attackers (able to inject WLAN frames) to trigger use-after-free conditions to potentially execute code.
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204059
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
- http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html
- http://www.openwall.com/lists/oss-security/2022/10/13/5
- https://bugzilla.suse.com/show_bug.cgi?id=1204059
- https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/
- https://security.netapp.com/advisory/ntap-20230203-0008/
- https://www.debian.org/security/2022/dsa-5257
Modified: 2025-05-07
CVE-2022-43750
drivers/usb/mon/mon_bin.c in usbmon in the Linux kernel before 5.19.15 and 6.x before 6.0.1 allows a user-space client to corrupt the monitor's internal memory.
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.15
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198
- https://github.com/torvalds/linux/commit/a659daf63d16aa883be42f3f34ff84235c302198
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.15
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.1
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198
- https://github.com/torvalds/linux/commit/a659daf63d16aa883be42f3f34ff84235c302198
- https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
Modified: 2025-09-19
CVE-2022-48631
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0
When walking through an inode extents, the ext4_ext_binsearch_idx() function
assumes that the extent header has been previously validated. However, there
are no checks that verify that the number of entries (eh->eh_entries) is
non-zero when depth is > 0. And this will lead to problems because the
EXT_FIRST_INDEX() and EXT_LAST_INDEX() will return garbage and result in this:
[ 135.245946] ------------[ cut here ]------------
[ 135.247579] kernel BUG at fs/ext4/extents.c:2258!
[ 135.249045] invalid opcode: 0000 [#1] PREEMPT SMP
[ 135.250320] CPU: 2 PID: 238 Comm: tmp118 Not tainted 5.19.0-rc8+ #4
[ 135.252067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014
[ 135.255065] RIP: 0010:ext4_ext_map_blocks+0xc20/0xcb0
[ 135.256475] Code:
[ 135.261433] RSP: 0018:ffffc900005939f8 EFLAGS: 00010246
[ 135.262847] RAX: 0000000000000024 RBX: ffffc90000593b70 RCX: 0000000000000023
[ 135.264765] RDX: ffff8880038e5f10 RSI: 0000000000000003 RDI: ffff8880046e922c
[ 135.266670] RBP: ffff8880046e9348 R08: 0000000000000001 R09: ffff888002ca580c
[ 135.268576] R10: 0000000000002602 R11: 0000000000000000 R12: 0000000000000024
[ 135.270477] R13: 0000000000000000 R14: 0000000000000024 R15: 0000000000000000
[ 135.272394] FS: 00007fdabdc56740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
[ 135.274510] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 135.276075] CR2: 00007ffc26bd4f00 CR3: 0000000006261004 CR4: 0000000000170ea0
[ 135.277952] Call Trace:
[ 135.278635]
- https://git.kernel.org/stable/c/29a5b8a137ac8eb410cc823653a29ac0e7b7e1b0
- https://git.kernel.org/stable/c/2f5e9de15e4f55fbf56f22d4a2ce406246cc462d
- https://git.kernel.org/stable/c/958b0ee23f5ac106e7cc11472b71aa2ea9a033bc
- https://git.kernel.org/stable/c/bb7eb3ca4b3b0d2c7872cf1a41c30f5e5bd65df0
- https://git.kernel.org/stable/c/be4df018c0be5ebecf1ca510feacc23be415cefc
- https://git.kernel.org/stable/c/29a5b8a137ac8eb410cc823653a29ac0e7b7e1b0
- https://git.kernel.org/stable/c/2f5e9de15e4f55fbf56f22d4a2ce406246cc462d
- https://git.kernel.org/stable/c/958b0ee23f5ac106e7cc11472b71aa2ea9a033bc
- https://git.kernel.org/stable/c/bb7eb3ca4b3b0d2c7872cf1a41c30f5e5bd65df0
- https://git.kernel.org/stable/c/be4df018c0be5ebecf1ca510feacc23be415cefc
Modified: 2025-03-04
CVE-2022-48632
In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() memcpy() is called in a loop while 'operation->length' upper bound is not checked and 'data_idx' also increments.
- https://git.kernel.org/stable/c/3b5ab5fbe69ebbee5692c72b05071a43fc0655d8
- https://git.kernel.org/stable/c/48ee0a864d1af02eea98fc825cc230d61517a71e
- https://git.kernel.org/stable/c/dc2a0c587006f29b724069740c48654b9dcaebd2
- https://git.kernel.org/stable/c/de24aceb07d426b6f1c59f33889d6a964770547b
- https://git.kernel.org/stable/c/3b5ab5fbe69ebbee5692c72b05071a43fc0655d8
- https://git.kernel.org/stable/c/48ee0a864d1af02eea98fc825cc230d61517a71e
- https://git.kernel.org/stable/c/dc2a0c587006f29b724069740c48654b9dcaebd2
- https://git.kernel.org/stable/c/de24aceb07d426b6f1c59f33889d6a964770547b
Modified: 2025-03-21
CVE-2022-48634
In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: Fix BUG: sleeping function called from invalid context errors
gma_crtc_page_flip() was holding the event_lock spinlock while calling
crtc_funcs->mode_set_base() which takes ww_mutex.
The only reason to hold event_lock is to clear gma_crtc->page_flip_event
on mode_set_base() errors.
Instead unlock it after setting gma_crtc->page_flip_event and on
errors re-take the lock and clear gma_crtc->page_flip_event it
it is still set.
This fixes the following WARN/stacktrace:
[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870
[ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell
[ 512.123031] preempt_count: 1, expected: 0
[ 512.123048] RCU nest depth: 0, expected: 0
[ 512.123066] INFO: lockdep is turned off.
[ 512.123080] irq event stamp: 0
[ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0
[ 512.123134] hardirqs last disabled at (0): [
- https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281
- https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd
- https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd
- https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b
- https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281
- https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd
- https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd
- https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b
Modified: 2025-03-21
CVE-2022-48636
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer with lcu->lock held.
- https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1
- https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4
- https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a2033036ac
- https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1
- https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6
- https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70
- https://git.kernel.org/stable/c/db7ba07108a48c0f95b74fabbfd5d63e924f992d
- https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b
- https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1
- https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4
- https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a2033036ac
- https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1
- https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6
- https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70
- https://git.kernel.org/stable/c/db7ba07108a48c0f95b74fabbfd5d63e924f992d
- https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b
Modified: 2025-01-13
CVE-2022-48639
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix possible refcount leak in tc_new_tfilter() tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops.
- https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88
- https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596
- https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a
- https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5
- https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7
- https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88
- https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596
- https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a
- https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5
- https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7
Modified: 2025-01-07
CVE-2022-48641
In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix memory leak when blob is malformed The bug fix was incomplete, it "replaced" crash with a memory leak. The old code had an assignment to "ret" embedded into the conditional, restore this.
- https://git.kernel.org/stable/c/11ebf32fde46572b0aaf3c2bdd97d923ef5a03ab
- https://git.kernel.org/stable/c/1e98318af2f163eadaff815abcef38d27ca92c1e
- https://git.kernel.org/stable/c/38cf372b17f0a5f35c1b716a100532d539f0eb33
- https://git.kernel.org/stable/c/62ce44c4fff947eebdf10bb582267e686e6835c9
- https://git.kernel.org/stable/c/754e8b74281dd54a324698803483f47cf3355ae1
- https://git.kernel.org/stable/c/d5917b7af7cae0e2804f9d127a03268035098b7f
- https://git.kernel.org/stable/c/ebd97dbe3c55d68346b9c5fb00634a7f5b10bbee
- https://git.kernel.org/stable/c/11ebf32fde46572b0aaf3c2bdd97d923ef5a03ab
- https://git.kernel.org/stable/c/1e98318af2f163eadaff815abcef38d27ca92c1e
- https://git.kernel.org/stable/c/38cf372b17f0a5f35c1b716a100532d539f0eb33
- https://git.kernel.org/stable/c/62ce44c4fff947eebdf10bb582267e686e6835c9
- https://git.kernel.org/stable/c/754e8b74281dd54a324698803483f47cf3355ae1
- https://git.kernel.org/stable/c/d5917b7af7cae0e2804f9d127a03268035098b7f
- https://git.kernel.org/stable/c/ebd97dbe3c55d68346b9c5fb00634a7f5b10bbee
Modified: 2025-01-07
CVE-2022-48642
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain() It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error.
- https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852
- https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714
- https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac
- https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88
- https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852
- https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714
- https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac
- https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88
Modified: 2025-09-18
CVE-2022-48643
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain() syzbot is reporting underflow of nft_counters_enabled counter at nf_tables_addchain() [1], for commit 43eb8949cfdffa76 ("netfilter: nf_tables: do not leave chain stats enabled on error") missed that nf_tables_chain_destroy() after nft_basechain_init() in the error path of nf_tables_addchain() decrements the counter because nft_basechain_init() makes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag. Increment the counter immediately after returning from nft_basechain_init().
- https://git.kernel.org/stable/c/710e3f526bd23a0d33435dedc52c3144de284378
- https://git.kernel.org/stable/c/8bcad2a931313aeba076b76922d5813ef97d0a91
- https://git.kernel.org/stable/c/91aa52652f4b37089aff3cb53e83049d826fef6d
- https://git.kernel.org/stable/c/921ebde3c0d22c8cba74ce8eb3cc4626abff1ccd
- https://git.kernel.org/stable/c/710e3f526bd23a0d33435dedc52c3144de284378
- https://git.kernel.org/stable/c/8bcad2a931313aeba076b76922d5813ef97d0a91
- https://git.kernel.org/stable/c/91aa52652f4b37089aff3cb53e83049d826fef6d
- https://git.kernel.org/stable/c/921ebde3c0d22c8cba74ce8eb3cc4626abff1ccd
Modified: 2025-09-19
CVE-2022-48644
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: avoid disabling offload when it was never enabled In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()). The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()). But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags). But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on an invalid set of flags. As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIO_FLAGS_INVALID, and the calling of taprio_enable_offload(). This is because drivers do not expect the offload to be disabled when it was never enabled. The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc: $ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2c Fix this by keeping track of the operations we made, and undo the offload only if we actually did it. I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64_t picos_per_byte". Now the first cache line looks like below: $ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */
- https://git.kernel.org/stable/c/586def6ebed195f3594a4884f7c5334d0e1ad1bb
- https://git.kernel.org/stable/c/c7c9c7eb305ab8b4e93e4e4e1b78d8cfcbc26323
- https://git.kernel.org/stable/c/d12a1eb07003e597077329767c6aa86a7e972c76
- https://git.kernel.org/stable/c/db46e3a88a09c5cf7e505664d01da7238cd56c92
- https://git.kernel.org/stable/c/f58e43184226e5e9662088ccf1389e424a3a4cbd
- https://git.kernel.org/stable/c/586def6ebed195f3594a4884f7c5334d0e1ad1bb
- https://git.kernel.org/stable/c/c7c9c7eb305ab8b4e93e4e4e1b78d8cfcbc26323
- https://git.kernel.org/stable/c/d12a1eb07003e597077329767c6aa86a7e972c76
- https://git.kernel.org/stable/c/db46e3a88a09c5cf7e505664d01da7238cd56c92
- https://git.kernel.org/stable/c/f58e43184226e5e9662088ccf1389e424a3a4cbd
Modified: 2025-03-04
CVE-2022-48647
In the Linux kernel, the following vulnerability has been resolved:
sfc: fix TX channel offset when using legacy interrupts
In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but
that's not correct if efx_sepparate_tx_channels is false. In that case,
the offset is 0 because the tx queues are in the single existing channel
at index 0, together with the rx queue.
Without this fix, as soon as you try to send any traffic, it tries to
get the tx queues from an uninitialized channel getting these errors:
WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]
[...]
RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]
[...]
Call Trace:
- https://git.kernel.org/stable/c/360910b88d1466a90644a4e0533803b594344a2b
- https://git.kernel.org/stable/c/5f623a77cfc2d501d72bcb4f9ee71721e6c766ff
- https://git.kernel.org/stable/c/b4afd3878f961d3517f27b3213730fceef77945c
- https://git.kernel.org/stable/c/f232af4295653afa4ade3230462b3be15ad16419
- https://git.kernel.org/stable/c/360910b88d1466a90644a4e0533803b594344a2b
- https://git.kernel.org/stable/c/5f623a77cfc2d501d72bcb4f9ee71721e6c766ff
- https://git.kernel.org/stable/c/b4afd3878f961d3517f27b3213730fceef77945c
- https://git.kernel.org/stable/c/f232af4295653afa4ade3230462b3be15ad16419
Modified: 2025-01-14
CVE-2022-48648
In the Linux kernel, the following vulnerability has been resolved: sfc: fix null pointer dereference in efx_hard_start_xmit Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]
- https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3
- https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998
- https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7
- https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03
- https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3
- https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998
- https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7
- https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03
Modified: 2025-03-20
CVE-2022-48651
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following: ================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use "skb->head + skb->mac_header", out-of-bound access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac header in multicast to solve this out-of-bound bug.
- https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca
- https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be
- https://git.kernel.org/stable/c/81225b2ea161af48e093f58e8dfee6d705b16af4
- https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7
- https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638
- https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef12c4241
- https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef
- https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4
- https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca
- https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be
- https://git.kernel.org/stable/c/81225b2ea161af48e093f58e8dfee6d705b16af4
- https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7
- https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638
- https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef12c4241
- https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef
- https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4
Modified: 2024-11-21
CVE-2022-48654
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find() nf_osf_find() incorrectly returns true on mismatch, this leads to copying uninitialized memory area in nft_osf which can be used to leak stale kernel stack data to userspace.
- https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8
- https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47
- https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e
- https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764
- https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e
- https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8
- https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47
- https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e
- https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764
- https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e
Modified: 2024-11-21
CVE-2022-48656
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get() We should call of_node_put() for the reference returned by of_parse_phandle() in fail path or when it is not used anymore. Here we only need to move the of_node_put() before the check.
- https://git.kernel.org/stable/c/a17df55bf6d536712da6902a83db82b82e67d5a2
- https://git.kernel.org/stable/c/aa11dae059a439af82bae541b134f8f53ac177b5
- https://git.kernel.org/stable/c/dd5a6c5a08752b613e83ad2cb5133e72a64b876d
- https://git.kernel.org/stable/c/f9fdb0b86f087c2b7f6c6168dd0985a3c1eda87e
- https://git.kernel.org/stable/c/a17df55bf6d536712da6902a83db82b82e67d5a2
- https://git.kernel.org/stable/c/aa11dae059a439af82bae541b134f8f53ac177b5
- https://git.kernel.org/stable/c/dd5a6c5a08752b613e83ad2cb5133e72a64b876d
- https://git.kernel.org/stable/c/f9fdb0b86f087c2b7f6c6168dd0985a3c1eda87e
Modified: 2024-11-21
CVE-2022-48657
In the Linux kernel, the following vulnerability has been resolved: arm64: topology: fix possible overflow in amu_fie_setup() cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. Multiplying max frequency by 1000 can potentially result in overflow -- multiplying by 1000ULL instead should avoid that... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
- https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549
- https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e
- https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb
- https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca
- https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549
- https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e
- https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb
- https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca
Modified: 2024-11-21
CVE-2022-48659
In the Linux kernel, the following vulnerability has been resolved: mm/slub: fix to return errno if kmalloc() fails In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 legacy_get_tree+0x30/0x74 fs/fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568
- https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9
- https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e9501940296
- https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c
- https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124
- https://git.kernel.org/stable/c/7e9c323c52b379d261a72dc7bd38120a761a93cd
- https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c
- https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457
- https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755
- https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9
- https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e9501940296
- https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c
- https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124
- https://git.kernel.org/stable/c/7e9c323c52b379d261a72dc7bd38120a761a93cd
- https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c
- https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457
- https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755
Modified: 2024-11-21
CVE-2022-48660
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully When running gpio test on nxp-ls1028 platform with below command gpiomon --num-events=3 --rising-edge gpiochip1 25 There will be a warning trace as below: Call trace: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... el0t_64_sync+0x1a0/0x1a4 The reason of this issue is that calling request_threaded_irq() function failed, and then lineevent_free() is invoked to release the resource. Since the lineevent_state::irq was already set, so the subsequent invocation of free_irq() would trigger the above warning call trace. To fix this issue, set the lineevent_state::irq after the IRQ register successfully.
- https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd
- https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1
- https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168
- https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43
- https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd
- https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1
- https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168
- https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43
Modified: 2025-01-14
CVE-2022-48663
In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: fix NULL pointer dereference when removing debugfs We now remove the device's debugfs entries when unbinding the driver. This now causes a NULL-pointer dereference on module exit because the platform devices are unregistered *after* the global debugfs directory has been recursively removed. Fix it by unregistering the devices first.
- https://git.kernel.org/stable/c/18352095a0d581f6aeb1e9fc9d68cc0152cd64b4
- https://git.kernel.org/stable/c/af0bfabf06c74c260265c30ba81a34e7dec0e881
- https://git.kernel.org/stable/c/b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68
- https://git.kernel.org/stable/c/bdea98b98f844bd8a983ca880893e509a8b4162f
- https://git.kernel.org/stable/c/18352095a0d581f6aeb1e9fc9d68cc0152cd64b4
- https://git.kernel.org/stable/c/af0bfabf06c74c260265c30ba81a34e7dec0e881
- https://git.kernel.org/stable/c/b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68
- https://git.kernel.org/stable/c/bdea98b98f844bd8a983ca880893e509a8b4162f
Modified: 2025-09-26
CVE-2022-48664
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix hang during unmount when stopping a space reclaim worker
Often when running generic/562 from fstests we can hang during unmount,
resulting in a trace like this:
Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00
Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds.
Sep 07 11:55:32 debian9 kernel: Not tainted 6.0.0-rc2-btrfs-next-122 #1
Sep 07 11:55:32 debian9 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 07 11:55:32 debian9 kernel: task:umount state:D stack: 0 pid:49438 ppid: 25683 flags:0x00004000
Sep 07 11:55:32 debian9 kernel: Call Trace:
Sep 07 11:55:32 debian9 kernel:
- https://git.kernel.org/stable/c/6ac5b52e3f352f9cb270c89e6e1d4dadb564ddb8
- https://git.kernel.org/stable/c/a362bb864b8db4861977d00bd2c3222503ccc34b
- https://git.kernel.org/stable/c/c338bea1fec5504290dc0acf026c9e7dba25004b
- https://git.kernel.org/stable/c/d8a76a2e514fbbb315a6dfff2d342de2de833994
- https://git.kernel.org/stable/c/6ac5b52e3f352f9cb270c89e6e1d4dadb564ddb8
- https://git.kernel.org/stable/c/a362bb864b8db4861977d00bd2c3222503ccc34b
- https://git.kernel.org/stable/c/c338bea1fec5504290dc0acf026c9e7dba25004b
- https://git.kernel.org/stable/c/d8a76a2e514fbbb315a6dfff2d342de2de833994
Modified: 2025-10-01
CVE-2022-49733
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix race at SNDCTL_DSP_SYNC There is a small race window at snd_pcm_oss_sync() that is called from OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls snd_pcm_oss_make_ready() at first, then takes the params_lock mutex for the rest. When the stream is set up again by another thread between them, it leads to inconsistency, and may result in unexpected results such as NULL dereference of OSS buffer as a fuzzer spotted recently. The fix is simply to cover snd_pcm_oss_make_ready() call into the same params_lock mutex with snd_pcm_oss_make_ready_locked() variant.
- https://git.kernel.org/stable/c/4051324a6dafd7053c74c475e80b3ba10ae672b0
- https://git.kernel.org/stable/c/723ac5ab2891b6c10dd6cc78ef5456af593490eb
- https://git.kernel.org/stable/c/8015ef9e8a0ee5cecfd0cb6805834d007ab26f86
- https://git.kernel.org/stable/c/8423f0b6d513b259fdab9c9bf4aaa6188d054c2d
- https://git.kernel.org/stable/c/fce793a056c604b41a298317cf704dae255f1b36
Modified: 2025-11-24
CVE-2022-50234
In the Linux kernel, the following vulnerability has been resolved: io_uring/af_unix: defer registered files gc to io_uring release Instead of putting io_uring's registered files in unix_gc() we want it to be done by io_uring itself. The trick here is to consider io_uring registered files for cycle detection but not actually putting them down. Because io_uring can't register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with io_ring_ctx_free(). [axboe: add kerneldoc comment to skb, fold in skb leak fix]
- https://git.kernel.org/stable/c/0091bfc81741b8d3aeb3b7ab8636f911b2de6e80
- https://git.kernel.org/stable/c/04df9719df1865f6770af9bc7880874af0e594b2
- https://git.kernel.org/stable/c/75e94c7e8859e58aadc15a98cc9704edff47d4f2
- https://git.kernel.org/stable/c/813d8fe5d30388f73a21d3a2bf46b0a1fd72498c
- https://git.kernel.org/stable/c/b4293c01ee0d0ecdd3cb5801e13f62271144667a
- https://git.kernel.org/stable/c/c378c479c5175833bb22ff71974cda47d7b05401
Modified: 2025-11-25
CVE-2022-50241
In the Linux kernel, the following vulnerability has been resolved: NFSD: fix use-after-free on source server when doing inter-server copy Use-after-free occurred when the laundromat tried to free expired cpntf_state entry on the s2s_cp_stateids list after inter-server copy completed. The sc_cp_list that the expired copy state was inserted on was already freed. When COPY completes, the Linux client normally sends LOCKU(lock_state x), FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server. The nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state from the s2s_cp_stateids list before freeing the lock state's stid. However, sometimes the CLOSE was sent before the FREE_STATEID request. When this happens, the nfsd4_close_open_stateid call from nfsd4_close frees all lock states on its st_locks list without cleaning up the copy state on the sc_cp_list list. When the time the FREE_STATEID arrives the server returns BAD_STATEID since the lock state was freed. This causes the use-after-free error to occur when the laundromat tries to free the expired cpntf_state. This patch adds a call to nfs4_free_cpntf_statelist in nfsd4_close_open_stateid to clean up the copy state before calling free_ol_stateid_reaplist to free the lock state's stid on the reaplist.
- https://git.kernel.org/stable/c/019805fea91599b22dfa62ffb29c022f35abeb06
- https://git.kernel.org/stable/c/35aa0fb8c3033a3d78603356e96fc18c5b9cceb2
- https://git.kernel.org/stable/c/6ea71246b7a02af675d733e72d14bd0d591d5f4a
- https://git.kernel.org/stable/c/83b94969751a691347606dbe6b1865efcfa5a643
- https://git.kernel.org/stable/c/bbacfcde5fff25ac22597e8373a065c647da6738
Modified: 2025-11-24
CVE-2022-50243
In the Linux kernel, the following vulnerability has been resolved: sctp: handle the error returned from sctp_auth_asoc_init_active_key When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens.
- https://git.kernel.org/stable/c/022152aaebe116a25c39818a07e175a8cd3c1e11
- https://git.kernel.org/stable/c/0f90099d18e3abdc01babf686f41f63fe04939c1
- https://git.kernel.org/stable/c/19d636b663e0e92951bba5fced929ca7fd25c552
- https://git.kernel.org/stable/c/382ff44716603a54f5fd238ddec6a2468e217612
- https://git.kernel.org/stable/c/3b0fcf5e29c0940e1169ce9c44f73edd98bdf12d
- https://git.kernel.org/stable/c/b8fa99a3a11bdd77fef6b4a97f1021eb30b5ba40
- https://git.kernel.org/stable/c/f65955340e0044f5c41ac799a01698ac7dee8a4e
Modified: 2025-11-25
CVE-2022-50249
In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount.
- https://git.kernel.org/stable/c/05215fb32010d4afb68fbdbb4d237df6e2d4567b
- https://git.kernel.org/stable/c/1c6cac6fa4d08aea161f83d38117d733b3c3a000
- https://git.kernel.org/stable/c/2680690f9ce4e6abbb4f559e97271c15b7eeda97
- https://git.kernel.org/stable/c/62ccab6e3376f8a22167c3b81468ae4f3e7d25f1
- https://git.kernel.org/stable/c/68c9c4e6495b825be3a8946df1a0148399555fe4
- https://git.kernel.org/stable/c/85a40bfb8e7a170abcf9dae2c0898a1983e48daa
- https://git.kernel.org/stable/c/a4d0bd4388e1a39df47e8aaa044ef6a7ee626e48
- https://git.kernel.org/stable/c/a4f7eb83852a65b6f8dea7dcc42b7c76d4d9b0a3
- https://git.kernel.org/stable/c/daaec4b3fe2297b022c6b2d6bf48b6e5265a60b9
Modified: 2025-12-03
CVE-2022-50271
In the Linux kernel, the following vulnerability has been resolved:
vhost/vsock: Use kvmalloc/kvfree for larger packets.
When copying a large file over sftp over vsock, data size is usually 32kB,
and kmalloc seems to fail to try to allocate 32 32kB regions.
vhost-5837: page allocation failure: order:4, mode:0x24040c0
Call Trace:
[
- https://git.kernel.org/stable/c/0d720c3f0a03e97867deab7e480ba3d3e19837ba
- https://git.kernel.org/stable/c/0e3f72931fc47bb81686020cc643cde5d9cd0bb8
- https://git.kernel.org/stable/c/36c9f340c60413e28f980c0224c4e9d35851526b
- https://git.kernel.org/stable/c/7aac8c63f604e6a6a46560c0f0188cd0332cf320
- https://git.kernel.org/stable/c/a99fc6d818161d6f1ff3307de8bf5237f6cc34d8
- https://git.kernel.org/stable/c/b4a5905fd2ef841cd61e969ea692c213c2e5c1f7
- https://git.kernel.org/stable/c/e28a4e7f0296824c61a81e7fd54ab48bad3e75ad
- https://git.kernel.org/stable/c/e6d0152c95108651f1880c1ddfab47cb9e3e62d0
Modified: 2025-12-03
CVE-2022-50273
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on destination blkaddr during recovery
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=216456
loop5: detected capacity change from 0 to 131072
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): Bitmap was wrongly set, blk:5634
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198
RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]
Call Trace:
- https://git.kernel.org/stable/c/0ef4ca04a3f9223ff8bc440041c524b2123e09a3
- https://git.kernel.org/stable/c/3a4d24d746866dd45d970bd565ff3886e839366a
- https://git.kernel.org/stable/c/68b1e607559d3dc85f94b0d738d7c4e8029b0cfa
- https://git.kernel.org/stable/c/73fb4bd2c055a393816f078f158cdd3025006f1d
- https://git.kernel.org/stable/c/8f0a47def4722c5fd8d6b9268b5ffed8a249e2db
- https://git.kernel.org/stable/c/ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362
Modified: 2025-12-04
CVE-2022-50281
In the Linux kernel, the following vulnerability has been resolved: MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create() In error case in bridge_platform_create after calling platform_device_add()/platform_device_add_data()/ platform_device_add_resources(), release the failed 'pdev' or it will be leak, call platform_device_put() to fix this problem. Besides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd', use platform_device_unregister() to release sgi_w1 resources when xtalk-bridge registration fails.
- https://git.kernel.org/stable/c/11bec9cba4de06b3c0e9e4041453c2caaa1cbec1
- https://git.kernel.org/stable/c/48025893b3e31b917ad654d28d23fff66681cac4
- https://git.kernel.org/stable/c/93296e7ab774230b7c36541dead10b6da39b650f
- https://git.kernel.org/stable/c/d7ac29e60d0ff71e9e414af595b8c92800f7fa90
- https://git.kernel.org/stable/c/da2aecef866b476438d02c662507a0e4e818da9d
Modified: 2025-12-04
CVE-2022-50296
In the Linux kernel, the following vulnerability has been resolved: UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---
- https://git.kernel.org/stable/c/16c546e148fa6d14a019431436a6f7b4087dbccd
- https://git.kernel.org/stable/c/2e3863cc02c156b51b50592d43ffa6a13b680b0d
- https://git.kernel.org/stable/c/5177bdc38eaa1c1ca6302214ab06913540cd00a2
- https://git.kernel.org/stable/c/6a73e6edcbf3cdd82796dcdf0c0f5fe5d91021af
- https://git.kernel.org/stable/c/7efe61dc6aa45aab8a40e304fa2dae21e33b0db4
- https://git.kernel.org/stable/c/844748412be03a236dcf4a208b588162a275e189
- https://git.kernel.org/stable/c/8f96aa67c2ccbd7e41b8dc992b8d13cfe206d571
- https://git.kernel.org/stable/c/cd251d39b13485eb94ee65bb000d024e02c00e45
- https://git.kernel.org/stable/c/dbd964a733db015bbb9dff592c259c736398140f
Modified: 2025-12-04
CVE-2022-50299
In the Linux kernel, the following vulnerability has been resolved:
md: Replace snprintf with scnprintf
Current code produces a warning as shown below when total characters
in the constituent block device names plus the slashes exceeds 200.
snprintf() returns the number of characters generated from the given
input, which could cause the expression “200 – len” to wrap around
to a large positive number. Fix this by using scnprintf() instead,
which returns the actual number of characters written into the buffer.
[ 1513.267938] ------------[ cut here ]------------
[ 1513.267943] WARNING: CPU: 15 PID: 37247 at
- https://git.kernel.org/stable/c/1727fd5015d8f93474148f94e34cda5aa6ad4a43
- https://git.kernel.org/stable/c/3b0a2bd51f60418ecd67493586a2bb2174199de3
- https://git.kernel.org/stable/c/41ca95033a0c47cd6dace1f0a36a6eb5ebe799e6
- https://git.kernel.org/stable/c/5d8259c9d1915a50c60c7d6e9e7fb9b7da64a175
- https://git.kernel.org/stable/c/76694e9ce0b2238c0a5f3ba54f9361dd3770ec78
- https://git.kernel.org/stable/c/897b1450abe5a67c842a5d24173ce4449ccdfa94
- https://git.kernel.org/stable/c/97238b88583c27c9d3b4a0cedb45f816523f17c3
- https://git.kernel.org/stable/c/f95825c4e51cf9a653b0ef947ac78401fc9d3a40
Modified: 2025-12-04
CVE-2022-50301
In the Linux kernel, the following vulnerability has been resolved: iommu/omap: Fix buffer overflow in debugfs There are two issues here: 1) The "len" variable needs to be checked before the very first write. Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a buffer overflow. 2) The snprintf() function returns the number of bytes that *would* have been copied if there were enough space. But we want to know the number of bytes which were *actually* copied so use scnprintf() instead.
- https://git.kernel.org/stable/c/0c7043a5b5c3b35f5dc8875757f71e7f491d64d4
- https://git.kernel.org/stable/c/184233a5202786b20220acd2d04ddf909ef18f29
- https://git.kernel.org/stable/c/2fee0dbfaeaaa4bda04279ce772c4572b1429d04
- https://git.kernel.org/stable/c/4010a1afaae1c0fb9c2cac5de703bed29b1f1782
- https://git.kernel.org/stable/c/648472df221f2bbffb433b964bcb87baccc586d8
- https://git.kernel.org/stable/c/706e359cf046c142db290244c3f4938b20fbe805
- https://git.kernel.org/stable/c/9814cc350e0765ce69244bf55ae4c8b29facd27e
- https://git.kernel.org/stable/c/bd0438f534b2e31b12f0b39b355c5dc2bbdaf854
- https://git.kernel.org/stable/c/ec53b99b6b9da8b501f001595a6260c03b42d5b7
Modified: 2025-12-04
CVE-2022-50309
In the Linux kernel, the following vulnerability has been resolved: media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init of_get_child_by_name() 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/1c78f19c3a0ea312a8178a6bfd8934eb93e9b10a
- https://git.kernel.org/stable/c/22b93530bbe6af9dce8e520bb6e978d1bda39d2b
- https://git.kernel.org/stable/c/2630cc88327a5557aa0d9cc63be95e3c6e0a55b3
- https://git.kernel.org/stable/c/2ea7caa9684687cf3adc1467cf4af3653a776192
- https://git.kernel.org/stable/c/3336210948b22c2db43e9df2ea403d251b4d24ab
- https://git.kernel.org/stable/c/3c38467c3255c428cdbd3cefaccca4662f302dc9
- https://git.kernel.org/stable/c/59b315353252abe7b8fdb8651ca31b8484ce287a
- https://git.kernel.org/stable/c/6e7b3b1e4e9f739800cd8010b75a9bee8d808cee
- https://git.kernel.org/stable/c/7b0efe7534071e0153708886355d80db69525d50
Modified: 2025-12-04
CVE-2022-50312
In the Linux kernel, the following vulnerability has been resolved: drivers: serial: jsm: fix some leaks in probe This error path needs to unwind instead of just returning directly.
- https://git.kernel.org/stable/c/1d5859ef229e381f4db38dce8ed58e4bf862006b
- https://git.kernel.org/stable/c/3bf05c2650cf6b8d83bf0b0d808cc78c6ee7e84c
- https://git.kernel.org/stable/c/3ea1fd63fdf0e83b491c2a9f25b395aa0e4bf6e8
- https://git.kernel.org/stable/c/6066bd69ffba3a6abc7c0793ccba1da79b7d77e3
- https://git.kernel.org/stable/c/6be8e565a4a60530797a974d0a3d0e30656166a1
- https://git.kernel.org/stable/c/71ffe5111f0ffa2fd43c14fd176c6f05d4e82212
- https://git.kernel.org/stable/c/737594536dc3ce732976c0d84bb1dcc842065521
- https://git.kernel.org/stable/c/744c2d33a88b082d9d504520f0132b3d688547b2
- https://git.kernel.org/stable/c/ff9a5e50fb1910be33e62925bc7ee3bef474879e
Modified: 2025-12-04
CVE-2022-50314
In the Linux kernel, the following vulnerability has been resolved: nbd: Fix hung when signal interrupts nbd_start_device_ioctl() syzbot reported hung task [1]. The following program is a simplified version of the reproducer: int main(void) { int sv[2], fd; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 1; if ((fd = open("/dev/nbd0", 0)) < 0) return 1; if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0) return 1; if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0) return 1; if (ioctl(fd, NBD_DO_IT) < 0) return 1; return 0; } When signal interrupt nbd_start_device_ioctl() waiting the condition atomic_read(&config->recv_threads) == 0, the task can hung because it waits the completion of the inflight IOs. This patch fixes the issue by clearing queue, not just shutdown, when signal interrupt nbd_start_device_ioctl().
- https://git.kernel.org/stable/c/1de7c3cf48fc41cd95adb12bd1ea9033a917798a
- https://git.kernel.org/stable/c/3575949513ea3b387b30dac1e69468a923c86caf
- https://git.kernel.org/stable/c/35fb7d4a53d9e36d1b91161ea9870d9c6d57dccf
- https://git.kernel.org/stable/c/3ba3846cb3e2fb3c6fbf79e998472821b298419e
- https://git.kernel.org/stable/c/62006a72b05e0d38727eef5188700f2488be5e89
- https://git.kernel.org/stable/c/b2700f98b3f4dd19fb4315b70581e5caff89eb49
- https://git.kernel.org/stable/c/c0d73be0af8c1310713bc39a8d7a22e35084e14f
- https://git.kernel.org/stable/c/c7b4641bd2395c2f3cd3b0a0cbf292ed9d489398
Modified: 2025-12-04
CVE-2022-50317
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: megachips: Fix a null pointer dereference bug When removing the module we will get the following warning: [ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered [ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI [ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130 [ 31.921825] Call Trace: [ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw] [ 31.923139] i2c_device_remove+0x181/0x1f0 The two bridges (stdp2690, stdp4028) do not probe at the same time, so the driver does not call ge_b850v3_resgiter() when probing, causing the driver to try to remove the object that has not been initialized. Fix this by checking whether both the bridges are probed.
- https://git.kernel.org/stable/c/1daf69228e310938177119c4eadcd30fc75c81e0
- https://git.kernel.org/stable/c/1ff673333d46d2c1b053ebd0c1c7c7c79e36943e
- https://git.kernel.org/stable/c/21764467ab396d9f08921e0a5ffa1214244e1ad9
- https://git.kernel.org/stable/c/4610e7a4111fa3f3ce27c09d6d94008c55f1cd31
- https://git.kernel.org/stable/c/5bc20bafcd87ba0858ab772cefc7047cb51bc249
- https://git.kernel.org/stable/c/7371fad5cfe6eada6bb5523c895fd6074b15c2b9
- https://git.kernel.org/stable/c/877e92e9b1bdeb580b31a46061005936be902cd4
- https://git.kernel.org/stable/c/aaa512ad1e59f2edf8a9e4f2b167a44b24670679
Modified: 2025-12-04
CVE-2022-50328
In the Linux kernel, the following vulnerability has been resolved: jbd2: fix potential use-after-free in jbd2_fc_wait_bufs In 'jbd2_fc_wait_bufs' use 'bh' after put buffer head reference count which may lead to use-after-free. So judge buffer if uptodate before put buffer head reference count.
- https://git.kernel.org/stable/c/1d4d16daec2a6689b6d3fbfc7d2078643adc6619
- https://git.kernel.org/stable/c/243d1a5d505d0b0460c9af0ad56ed4a56ef0bebd
- https://git.kernel.org/stable/c/2e6d9f381c1ed844531a577783fc352de7a44c8a
- https://git.kernel.org/stable/c/d11d2ded293976a1a0d9d9471827a44dc9e3c63f
- https://git.kernel.org/stable/c/effd9b3c029ecdd853a11933dcf857f5a7ca8c3d
Modified: 2025-12-04
CVE-2022-50330
In the Linux kernel, the following vulnerability has been resolved: crypto: cavium - prevent integer overflow loading firmware The "code_length" value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly. The "ntohl(ucode->code_length) * 2" multiplication can have an integer overflow.
- https://git.kernel.org/stable/c/172c8a24fc8312cf6b88d3c88469653fdcb1c127
- https://git.kernel.org/stable/c/2526d6bf27d15054bb0778b2f7bc6625fd934905
- https://git.kernel.org/stable/c/371fa5129af53a79f6dddc90fe5bb0825cbe72a4
- https://git.kernel.org/stable/c/3a720eb89026c5241b8c4abb33370dc6fb565eee
- https://git.kernel.org/stable/c/584561e94260268abe1c83e00d9c205565cb7bc5
- https://git.kernel.org/stable/c/90e483e7f20c32287d2a9da967e122938f52737a
- https://git.kernel.org/stable/c/c4d4c2afd08dfb3cd1c880d1811ede2568e81a6d
- https://git.kernel.org/stable/c/e29fd7a6852376d2cfb95ad5d6d3eeff93f815e9
Modified: 2026-01-14
CVE-2022-50344
In the Linux kernel, the following vulnerability has been resolved: ext4: fix null-ptr-deref in ext4_write_info I caught a null-ptr-deref bug as follows: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339 RIP: 0010:ext4_write_info+0x53/0x1b0 [...] Call Trace: dquot_writeback_dquots+0x341/0x9a0 ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0 generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130 deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0 exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================== Above issue may happen as follows: ------------------------------------- exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount dentry = sb->s_root sb->s_root = NULL <--- Here set NULL sync_filesystem __sync_filesystem sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <--- Null pointer dereference To solve this problem, we use ext4_journal_start_sb directly to avoid s_root being used.
- https://git.kernel.org/stable/c/3638aa1c7d87c0ca0aef23cf58cae2c48e7daca4
- https://git.kernel.org/stable/c/4a657319cfabd6199fd0b7b65bbebf6ded7a11c1
- https://git.kernel.org/stable/c/533c60a0b97cee5daab376933f486207e6680fb7
- https://git.kernel.org/stable/c/947264e00c46de19a016fd81218118c708fed2f3
- https://git.kernel.org/stable/c/bb420e8afc854d2a1caaa23a0c129839acfb7888
- https://git.kernel.org/stable/c/dc451578446afd03c0c21913993c08898a691435
- https://git.kernel.org/stable/c/f34ab95162763cd7352f46df169296eec28b688d
- https://git.kernel.org/stable/c/f4b5ff0b794aa94afac7269c494550ca2f66511b
- https://git.kernel.org/stable/c/f9c1f248607d5546075d3f731e7607d5571f2b60
Modified: 2026-01-14
CVE-2022-50348
In the Linux kernel, the following vulnerability has been resolved: nfsd: Fix a memory leak in an error handling path If this memdup_user() call fails, the memory allocated in a previous call a few lines above should be freed. Otherwise it leaks.
- https://git.kernel.org/stable/c/733dd17158f96aaa25408dc39bbb2738fda9300e
- https://git.kernel.org/stable/c/acc393aecda05bf64ed13b732931462e07a1bf08
- https://git.kernel.org/stable/c/aed8816305575b38dcc77feb6f1bc1d0ed32f5b8
- https://git.kernel.org/stable/c/cc3bca2110ac85cd964da997ef83d84cab0d49fb
- https://git.kernel.org/stable/c/e060c4b9f33c1fca74df26d57a98e784295327e6
- https://git.kernel.org/stable/c/fd1ef88049de09bc70d60b549992524cfc0e66ff
Modified: 2026-01-14
CVE-2022-50355
In the Linux kernel, the following vulnerability has been resolved: staging: vt6655: fix some erroneous memory clean-up loops In some initialization functions of this driver, memory is allocated with 'i' acting as an index variable and increasing from 0. The commit in "Fixes" introduces some clean-up codes in case of allocation failure, which free memory in reverse order with 'i' decreasing to 0. However, there are some problems: - The case i=0 is left out. Thus memory is leaked. - In case memory allocation fails right from the start, the memory freeing loops will start with i=-1 and invalid memory locations will be accessed. One of these loops has been fixed in commit c8ff91535880 ("staging: vt6655: fix potential memory leak"). Fix the remaining erroneous loops.
- https://git.kernel.org/stable/c/2a2db520e3ca5aafba7c211abfd397666c9b5f9d
- https://git.kernel.org/stable/c/637672a71f5016a40b0a6c0f3c8ad25eacedc8c3
- https://git.kernel.org/stable/c/88b9cc60f26e8a05d1ddbddf91b09ca2915f20e0
- https://git.kernel.org/stable/c/95ac62e8545be2b0a8cae0beef7c682e2e470e48
- https://git.kernel.org/stable/c/a9e9806d1c315bc50dce05479a079b9a104474b8
- https://git.kernel.org/stable/c/ed11b73c963292e7b49c0f37025c58ed3b7921d6
- https://git.kernel.org/stable/c/f19e5b7df54590c831f350381963f25585c8f7d5
Modified: 2026-01-14
CVE-2022-50359
In the Linux kernel, the following vulnerability has been resolved: media: cx88: Fix a null-ptr-deref bug in buffer_prepare() When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue(). The following log can reveal it: [ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516] __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0 Fix this by checking the return value of cx88_risc_buffer() [hverkuil: fix coding style issues]
- https://git.kernel.org/stable/c/10c99d1c46ea9cd940029e17bab11d021f315c21
- https://git.kernel.org/stable/c/2b064d91440b33fba5b452f2d1b31f13ae911d71
- https://git.kernel.org/stable/c/4befc7ffa18ef9a4b70d854465313a345a06862f
- https://git.kernel.org/stable/c/644d5a87ab1863eb606526ea743021752a17e9cb
- https://git.kernel.org/stable/c/6f21976095c1e92454ab030976f95f40d652351b
- https://git.kernel.org/stable/c/704838040f3bdb4aa07ff4f26505a666a3defcfe
- https://git.kernel.org/stable/c/9181af2dbf06e7f432e5dbe88d10b22343e851b9
- https://git.kernel.org/stable/c/c2257c8a501537afab276c306cb717b7260276e1
- https://git.kernel.org/stable/c/c76d04d2079a4b7369ce9a0e859c0f3f2250bcc1
Modified: 2026-01-14
CVE-2022-50362
In the Linux kernel, the following vulnerability has been resolved: dmaengine: hisilicon: Add multi-thread support for a DMA channel When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103] ESR = 0x96000044 [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107] SET = 0, FnV = 0 [383493.335108] EA = 0, S1PTW = 0 [383493.335109] FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111] ISV = 0, ISS = 0x00000044 [383493.364739] CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0 This occurs because the transmission timed out, and that's due to data race. Each thread rewrite channels's descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels's descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That's why timeout reports. With current fixes channels' descriptor changes it's value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel's descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing.
- https://git.kernel.org/stable/c/2cbb95883c990d0002a77e13d3278913ab26ad79
- https://git.kernel.org/stable/c/7cb9b20941e1fb20d22d0a2f460a3d4fa417274c
- https://git.kernel.org/stable/c/af12e209a9d559394d35875ba0e6c80407605888
- https://git.kernel.org/stable/c/d4a8ec5cc7ff5d442bd49a44f26d74b2021ba4c8
- https://git.kernel.org/stable/c/f4cee0b385cd0348e071d4d80c4c13cfe547c70d
Modified: 2026-01-14
CVE-2022-50366
In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds: shift exponent 18446744073709551615 is too large for 32-bit type 'int' Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us
- https://git.kernel.org/stable/c/139bbbd01114433b80fe59f5e1330615aadf9752
- https://git.kernel.org/stable/c/1d94af37565e4d3c26b0d63428e093a37d5b4c32
- https://git.kernel.org/stable/c/2d93540014387d1c73b9ccc4d7895320df66d01b
- https://git.kernel.org/stable/c/3eb0ba70376f6ee40fa843fc9cee49269370b0b3
- https://git.kernel.org/stable/c/42f79dbb9514f726ff21df25f09cb0693b0b2445
- https://git.kernel.org/stable/c/49a6ffdaed60f0eb52c198fafebc05994e16e305
- https://git.kernel.org/stable/c/4ebba43384722adbd325baec3a12c572d94488eb
- https://git.kernel.org/stable/c/6216b685b8f48ab7b721a6fd5acbf526b41c13e8
- https://git.kernel.org/stable/c/708b9abe1b4a2f050a483db4b7edfc446b13df1f
Modified: 2026-01-14
CVE-2022-50367
In the Linux kernel, the following vulnerability has been resolved: fs: fix UAF/GPF bug in nilfs_mdt_destroy In alloc_inode, inode_init_always() could return -ENOMEM if security_inode_alloc() fails, which causes inode->i_private uninitialized. Then nilfs_is_metadata_file_inode() returns true and nilfs_free_inode() wrongly calls nilfs_mdt_destroy(), which frees the uninitialized inode->i_private and leads to crashes(e.g., UAF/GPF). Fix this by moving security_inode_alloc just prior to this_cpu_inc(nr_inodes)
- https://git.kernel.org/stable/c/1e555c3ed1fce4b278aaebe18a64a934cece57d8
- https://git.kernel.org/stable/c/2a96b532098284ecf8e4849b8b9e5fc7a28bdee9
- https://git.kernel.org/stable/c/2e488f13755ffbb60f307e991b27024716a33b29
- https://git.kernel.org/stable/c/64b79e632869ad3ef6c098a4731d559381da1115
- https://git.kernel.org/stable/c/70e4f70d54e0225f91814e8610477d65f33cefe4
- https://git.kernel.org/stable/c/81de80330fa6907aec32eb54c5619059e6e36452
- https://git.kernel.org/stable/c/c0aa76b0f17f59dd9c9d3463550a2986a1d592e4
- https://git.kernel.org/stable/c/d1ff475d7c83289d0a7faef346ea3bbf90818bad
- https://git.kernel.org/stable/c/ec2aab115eb38ac4992ea2fcc2a02fbe7af5cf48
Modified: 2026-01-14
CVE-2022-50374
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1], for rcu_sync_enter() is called without rcu_sync_init() due to hci_uart_tty_open() ignoring percpu_init_rwsem() failure. While we are at it, fix that hci_uart_register_device() ignores percpu_init_rwsem() failure and hci_uart_unregister_device() does not call percpu_free_rwsem().
- https://git.kernel.org/stable/c/3124d320c22f3f4388d9ac5c8f37eaad0cefd6b1
- https://git.kernel.org/stable/c/75b2c71ea581c7bb1303860d89366a42ad0506d2
- https://git.kernel.org/stable/c/98ce10f3f345e61fc6c83bff9cd11cda252b05ac
- https://git.kernel.org/stable/c/b8917dce2134739b39bc0a5648b18427f2cad569
- https://git.kernel.org/stable/c/d7cc0d51ffcbfd1caaa809fcf9cff05c46d0fb4d
Modified: 2026-01-14
CVE-2022-50375
In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can still occur which in turn tries to access dma apis if lpuart_dma_tx_use flag is true. At this point since dma is torn down, these dma apis can abort. Set lpuart_dma_tx_use and the corresponding rx flag lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not accessed after they are relinquished. Otherwise, when try to kill btattach, kernel may panic. This patch may fix this issue. root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200 ^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 90.189806] Modules linked in: moal(O) mlan(O) [ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37 [ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT) [ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60 [ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c [ 90.225237] sp : ffff800013f0bac0 [ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800 [ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00 [ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000 [ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000 [ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040 [ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090 [ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804 [ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480 [ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800 [ 90.299876] Call trace: [ 90.302321] fsl_edma3_disable_request+0x8/0x60 [ 90.306851] lpuart_flush_buffer+0x40/0x160 [ 90.311037] uart_flush_buffer+0x88/0x120 [ 90.315050] tty_driver_flush_buffer+0x20/0x30 [ 90.319496] hci_uart_flush+0x44/0x90 [ 90.323162] +0x34/0x12c [ 90.327253] tty_ldisc_close+0x38/0x70 [ 90.331005] tty_ldisc_release+0xa8/0x190 [ 90.335018] tty_release_struct+0x24/0x8c [ 90.339022] tty_release+0x3ec/0x4c0 [ 90.342593] __fput+0x70/0x234 [ 90.345652] ____fput+0x14/0x20 [ 90.348790] task_work_run+0x84/0x17c [ 90.352455] do_exit+0x310/0x96c [ 90.355688] do_group_exit+0x3c/0xa0 [ 90.359259] __arm64_sys_exit_group+0x1c/0x20 [ 90.363609] invoke_syscall+0x48/0x114 [ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc [ 90.372068] do_el0_svc+0x2c/0x94 [ 90.375379] el0_svc+0x28/0x80 [ 90.378438] el0t_64_sync_handler+0xa8/0x130 [ 90.382711] el0t_64_sync+0x1a0/0x1a4 [ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041) [ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]--- [ 90.397073] note: btattach[503] exited with preempt_count 1 [ 90.402636] Fixing recursive fault but reboot is needed!
- https://git.kernel.org/stable/c/29b897ac7b990882c74bd08605692214e7e58b83
- https://git.kernel.org/stable/c/316ae95c175a7d770d1bfe4c011192712f57aa4a
- https://git.kernel.org/stable/c/3953e7f261e2f4d9c35f0c025df9f166f46aa626
- https://git.kernel.org/stable/c/9a56ade124d4891a31ab1300c57665f07f5b24d5
- https://git.kernel.org/stable/c/c4293def8860fd587a84400ccba5b49cec56e2c3
- https://git.kernel.org/stable/c/d554c14eb73ee91d76fc9aece4616f0b687c295d
Modified: 2026-01-14
CVE-2022-50379
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between quota enable and quota rescan ioctl When enabling quotas, at btrfs_quota_enable(), after committing the transaction, we change fs_info->quota_root to point to the quota root we created and set BTRFS_FS_QUOTA_ENABLED at fs_info->flags. Then we try to start the qgroup rescan worker, first by initializing it with a call to qgroup_rescan_init() - however if that fails we end up freeing the quota root but we leave fs_info->quota_root still pointing to it, this can later result in a use-after-free somewhere else. We have previously set the flags BTRFS_FS_QUOTA_ENABLED and BTRFS_QGROUP_STATUS_FLAG_ON, so we can only fail with -EINPROGRESS at btrfs_quota_enable(), which is possible if someone already called the quota rescan ioctl, and therefore started the rescan worker. So fix this by ignoring an -EINPROGRESS and asserting we can't get any other error.
- https://git.kernel.org/stable/c/0efd9dfc00d677a1d0929319a6103cb2dfc41c22
- https://git.kernel.org/stable/c/26b7c0ac49a3eea15559c9d84863736a6d1164b4
- https://git.kernel.org/stable/c/331cd9461412e103d07595a10289de90004ac890
- https://git.kernel.org/stable/c/47b5ffe86332af95f0f52be0a63d4da7c2b37b55
- https://git.kernel.org/stable/c/4b996a3014ef014af8f97b60c35f5289210a4720
- https://git.kernel.org/stable/c/6c22f86dd221eba0c7af645b1af73dcbc04ee27b
- https://git.kernel.org/stable/c/c97f6d528c3f1c83a6b792a8a7928c236c80b8fe
Modified: 2026-01-14
CVE-2022-50386
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix user-after-free This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
- https://git.kernel.org/stable/c/0c108cf3ad386e0084277093b55a351c49e0be27
- https://git.kernel.org/stable/c/11e40d6c0823f699d8ad501e48d1c3ae4be386cd
- https://git.kernel.org/stable/c/15fc21695eb606bdc5d483b92118ee42610a952d
- https://git.kernel.org/stable/c/35fcbc4243aad7e7d020b7c1dfb14bb888b20a4f
- https://git.kernel.org/stable/c/6ffde6e03085874ae22263ff4cef4869f797e84f
- https://git.kernel.org/stable/c/7d6f9cb24d2b2f6b6370eac074e2e6b1bafdad45
- https://git.kernel.org/stable/c/843fc4e386dd84b806a7f07fb062d8c3a44e5364
- https://git.kernel.org/stable/c/d1e894f950ad48897d1a7cb05909ea29d8c3810e
- https://git.kernel.org/stable/c/d91fc2836562f299f34e361e089e9fe154da4f73
Modified: 2026-01-14
CVE-2022-50400
In the Linux kernel, the following vulnerability has been resolved: staging: greybus: audio_helper: remove unused and wrong debugfs usage In the greybus audio_helper code, the debugfs file for the dapm has the potential to be removed and memory will be leaked. There is also the very real potential for this code to remove ALL debugfs entries from the system, and it seems like this is what will really happen if this code ever runs. This all is very wrong as the greybus audio driver did not create this debugfs file, the sound core did and controls the lifespan of it. So remove all of the debugfs logic from the audio_helper code as there's no way it could be correct. If this really is needed, it can come back with a fixup for the incorrect usage of the debugfs_lookup() call which is what caused this to be noticed at all.
- https://git.kernel.org/stable/c/4dab0d27a4211a27135a6899d6c737e6e0759a11
- https://git.kernel.org/stable/c/5699afbff1fa2972722e863906c0320d55dd4d58
- https://git.kernel.org/stable/c/d0febad83e29d85bb66e4f5cac0115b022403338
- https://git.kernel.org/stable/c/d517cdeb904ddc0cbebcc959d43596426cac40b0
- https://git.kernel.org/stable/c/d835fa49d9589a780ff0d001bb7e6323238a4afb
Modified: 2026-01-14
CVE-2022-50408
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit() > ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb); may be schedule, and then complete before the line > ndev->stats.tx_bytes += skb->len; [ 46.912801] ================================================================== [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328 [ 46.935991] [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1 [ 46.947255] Hardware name: [REDACTED] [ 46.954568] Call trace: [ 46.957037] dump_backtrace+0x0/0x2b8 [ 46.960719] show_stack+0x24/0x30 [ 46.964052] dump_stack+0x128/0x194 [ 46.967557] print_address_description.isra.0+0x64/0x380 [ 46.972877] __kasan_report+0x1d4/0x240 [ 46.976723] kasan_report+0xc/0x18 [ 46.980138] __asan_report_load4_noabort+0x18/0x20 [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0 [ 46.994894] sch_direct_xmit+0x198/0xd08 [ 46.998827] __qdisc_run+0x37c/0x1dc0 [ 47.002500] __dev_queue_xmit+0x1528/0x21f8 [ 47.006692] dev_queue_xmit+0x24/0x30 [ 47.010366] neigh_resolve_output+0x37c/0x678 [ 47.014734] ip_finish_output2+0x598/0x2458 [ 47.018927] __ip_finish_output+0x300/0x730 [ 47.023118] ip_output+0x2e0/0x430 [ 47.026530] ip_local_out+0x90/0x140 [ 47.030117] igmpv3_sendpack+0x14c/0x228 [ 47.034049] igmpv3_send_cr+0x384/0x6b8 [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118 [ 47.042262] call_timer_fn+0x1cc/0xbe8 [ 47.046021] __run_timers+0x4d8/0xb28 [ 47.049693] run_timer_softirq+0x24/0x40 [ 47.053626] __do_softirq+0x2c0/0x117c [ 47.057387] irq_exit+0x2dc/0x388 [ 47.060715] __handle_domain_irq+0xb4/0x158 [ 47.064908] gic_handle_irq+0x58/0xb0 [ 47.068581] el0_irq_naked+0x50/0x5c [ 47.072162] [ 47.073665] Allocated by task 328: [ 47.077083] save_stack+0x24/0xb0 [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0 [ 47.084776] kasan_slab_alloc+0x14/0x20 [ 47.088622] kmem_cache_alloc+0x15c/0x468 [ 47.092643] __alloc_skb+0xa4/0x498 [ 47.096142] igmpv3_newpack+0x158/0xd78 [ 47.099987] add_grhead+0x210/0x288 [ 47.103485] add_grec+0x6b0/0xb70 [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8 [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118 [ 47.115027] call_timer_fn+0x1cc/0xbe8 [ 47.118785] __run_timers+0x4d8/0xb28 [ 47.122457] run_timer_softirq+0x24/0x40 [ 47.126389] __do_softirq+0x2c0/0x117c [ 47.130142] [ 47.131643] Freed by task 180: [ 47.134712] save_stack+0x24/0xb0 [ 47.138041] __kasan_slab_free+0x108/0x180 [ 47.142146] kasan_slab_free+0x10/0x18 [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0 [ 47.150444] kmem_cache_free+0x8c/0x528 [ 47.154292] kfree_skbmem+0x94/0x108 [ 47.157880] consume_skb+0x10c/0x5a8 [ 47.161466] __dev_kfree_skb_any+0x88/0xa0 [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil] [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac] [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac] [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac] [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac] [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac] [ 47.197859] process_one_work+0x7fc/0x1a80 [ 47.201965] worker_thread+0x31c/0xc40 [ 47.205726] kthread+0x2d8/0x370 [ 47.208967] ret_from_fork+0x10/0x18 [ 47.212546] [ 47.214051] The buggy address belongs to the object at ffffff803f588280 [ 47.214051] which belongs to the cache skbuff_head_cache of size 208 [ 47.227086] The buggy address is located 104 bytes inside of [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350) [ 47.238814] The buggy address belongs to the page: [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcou ---truncated---
- https://git.kernel.org/stable/c/1613a7b24f1a7467cb727ba3ec77c9a808383560
- https://git.kernel.org/stable/c/232d59eca07f6ea27307022a33d226aff373bd02
- https://git.kernel.org/stable/c/27574a3f421c3a1694d0207f37c6bbf23d66978e
- https://git.kernel.org/stable/c/3f42faf6db431e04bf942d2ebe3ae88975723478
- https://git.kernel.org/stable/c/49c742afd60f552fce7799287080db02bffe1db2
- https://git.kernel.org/stable/c/c369836cff98d3877f98c98e15c0151462812d96
- https://git.kernel.org/stable/c/d79f4d903e14dde822c60b5fd3bedc5a289d25df
- https://git.kernel.org/stable/c/e01d96494a9de0f48b1167f0494f6d929fa773ed
Modified: 2025-12-23
CVE-2022-50409
In the Linux kernel, the following vulnerability has been resolved:
net: If sock is dead don't access sock's sk_wq in sk_stream_wait_memory
Fixes the below NULL pointer dereference:
[...]
[ 14.471200] Call Trace:
[ 14.471562]
- https://git.kernel.org/stable/c/124b7c773271f06af5a2cea694b283cdb5275cf5
- https://git.kernel.org/stable/c/35f5e70bdfa7432762ac4ffa75e5a7574ac5563e
- https://git.kernel.org/stable/c/3f8ef65af927db247418d4e1db49164d7a158fc5
- https://git.kernel.org/stable/c/435f5aa4421782af197b98d8525263977be4af5c
- https://git.kernel.org/stable/c/65029aaedd15d9fe5ea1a899134e236d83f627bb
- https://git.kernel.org/stable/c/a76462dbdd8bddcbeec9463bc9e54e509b860762
Modified: 2026-01-14
CVE-2022-50419
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times
device_add shall not be called multiple times as stated in its
documentation:
'Do not call this routine or device_register() more than once for
any device structure'
Syzkaller reports a bug as follows [1]:
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:33!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
[...]
Call Trace:
- https://git.kernel.org/stable/c/1b6c89571f453101251201f0fad1c26f7256e937
- https://git.kernel.org/stable/c/3423a50fa018e88aed4c900d59c3c8334d8ad583
- https://git.kernel.org/stable/c/448a496f760664d3e2e79466aa1787e6abc922b5
- https://git.kernel.org/stable/c/4bcefec3636208b4c97536b26014d5935d5c10a0
- https://git.kernel.org/stable/c/6144423712d570247b8ca26e50a277c30dd13702
- https://git.kernel.org/stable/c/671fee73e08ff415d36a7c16bdf238927df83884
- https://git.kernel.org/stable/c/6e85d2ad958c6f034b1b158d904019869dbb3c81
- https://git.kernel.org/stable/c/7b674dce4162bb46d396586e30e4653427023875
- https://git.kernel.org/stable/c/ef055094df4c10b73cfe67c8d43f9de1fb608a8b
Modified: 2026-01-14
CVE-2022-50422
In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix use-after-free bug in smp_execute_task_sg() When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete "slow_task->timer". However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below: (thread 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the "task->slow_task" is deallocated.
- https://git.kernel.org/stable/c/117331a2a5227fb4369c2a1f321d3e3e2e2ef8fe
- https://git.kernel.org/stable/c/2e12ce270f0d926085c1209cc90397e307deef97
- https://git.kernel.org/stable/c/46ba53c30666717cb06c2b3c5d896301cd00d0c0
- https://git.kernel.org/stable/c/a9e5176ead6de64f572ad5c87a72825d9d3c82ae
- https://git.kernel.org/stable/c/e45a1516d2933703a4823d9db71e17c3abeba24f
- https://git.kernel.org/stable/c/f7a785177611ffc97d645fcbc196e6de6ad2421d
Modified: 2026-01-21
CVE-2022-50429
In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount.
- https://git.kernel.org/stable/c/1d312c12c91f831fcc48623c921f2d4560edb159
- https://git.kernel.org/stable/c/3b321bf7687968a090cf6b62bd8e67d692f59a16
- https://git.kernel.org/stable/c/48af14fb0eaa63d9aa68f59fb0b205ec55a95636
- https://git.kernel.org/stable/c/7e053784c4c70df28324106d476778be7a4519b3
- https://git.kernel.org/stable/c/daab421fc2dc7d6ae7eb20a3f565ae09652c68b9
Modified: 2026-01-21
CVE-2022-50435
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid crash when inline data creation follows DIO write
When inode is created and written to using direct IO, there is nothing
to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets
truncated later to say 1 byte and written using normal write, we will
try to store the data as inline data. This confuses the code later
because the inode now has both normal block and inline data allocated
and the confusion manifests for example as:
kernel BUG at fs/ext4/inode.c:2721!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
RIP: 0010:ext4_writepages+0x363d/0x3660
RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293
RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180
RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000
RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b
R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128
R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001
FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0
Call Trace:
- https://git.kernel.org/stable/c/4bb26f2885ac6930984ee451b952c5a6042f2c0e
- https://git.kernel.org/stable/c/771f15782d95760cde352c8d4bfd6f2c70719568
- https://git.kernel.org/stable/c/89db2b50469bdbccb06ab072096d9d403124abac
- https://git.kernel.org/stable/c/d8e4af8314df54d94cf2a541cf9c8626afe81d41
- https://git.kernel.org/stable/c/fb98cb61efff3b2a1964939465ccaaf906af1d4f
Modified: 2026-01-16
CVE-2022-50444
In the Linux kernel, the following vulnerability has been resolved: clk: tegra20: Fix refcount leak in tegra20_clock_init 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.
- https://git.kernel.org/stable/c/0172d14f50098f5736b4b272a1529a3e05419bd6
- https://git.kernel.org/stable/c/4e343bafe03ff68a62f48f8235cf98f2c685468b
- https://git.kernel.org/stable/c/53531d00e2a8a28a3bf56ea58b18ff3611824f37
- https://git.kernel.org/stable/c/5d9fb09612defe7b1d5627db7b3833b46eb21e7b
- https://git.kernel.org/stable/c/6f76ef65899fcd93ca747ef38d7a41931e61e4fa
- https://git.kernel.org/stable/c/70f0a0a27d79f689defc5f5f0bd47d07813e6dea
- https://git.kernel.org/stable/c/8cd228892759d37f36a46616025f4fa0d0a63b5d
- https://git.kernel.org/stable/c/d6e750535b46e12cdde185b416c415e49e4e6e22
- https://git.kernel.org/stable/c/f9bdef9bb60814514a787b84184ecaa269a7c951
Modified: 2026-01-16
CVE-2022-50454
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in nouveau_gem_prime_import_sg_table() nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and free the memory.Thus, when nouveau_bo_init() returns an error, the gem object has already been released. Then the call to nouveau_bo_ref() will use the freed "nvbo->bo" and lead to a use-after-free bug. We should delete the call to nouveau_bo_ref() to avoid the use-after-free.
- https://git.kernel.org/stable/c/3aeda2fe6517cc52663d4ce3588dd43f0d4124a7
- https://git.kernel.org/stable/c/540dfd188ea2940582841c1c220bd035a7db0e51
- https://git.kernel.org/stable/c/56ee9577915dc06f55309901012a9ef68dbdb5a8
- https://git.kernel.org/stable/c/5d6093c49c098d86c7b136aba9922df44aeb6944
- https://git.kernel.org/stable/c/7d80473e9f12548ac05b36af4fb9ce80f2f73509
- https://git.kernel.org/stable/c/861f085f81fd569b02cc2c11165a9e6cca144424
Modified: 2026-01-16
CVE-2022-50458
In the Linux kernel, the following vulnerability has been resolved: clk: tegra: Fix refcount leak in tegra210_clock_init 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.
- https://git.kernel.org/stable/c/1a6d97139b0a370a9d0809a00e91c41f5bcd3ef1
- https://git.kernel.org/stable/c/417ed4432b1b40526b1cb50e535d46900505f6d9
- https://git.kernel.org/stable/c/56c78cb1f00a9dde8cd762131ce8f4c5eb046fbb
- https://git.kernel.org/stable/c/6d3ac23b952f374017e1a5249d1f03bdbc7f9878
- https://git.kernel.org/stable/c/a19360db83d29bd6b0de4ffad2c815d79246ba99
- https://git.kernel.org/stable/c/ac010ec3484ba95c6ab3d946f9a83560005c13c6
- https://git.kernel.org/stable/c/e715510adc20a4a07f157ece4e6d068e648a0383
- https://git.kernel.org/stable/c/f38f34ba1e1029b927b81b9bf9d952f4ed4007bd
- https://git.kernel.org/stable/c/f487137a53b1a0692211f7ae82c0a7f87c30bdbe
Modified: 2026-01-16
CVE-2022-50459
In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername() Fix a NULL pointer crash that occurs when we are freeing the socket at the same time we access it via sysfs. The problem is that: 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold() does a get on the "struct sock". 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put on the "struct socket" and that does __sock_release() which sets the sock->ops to NULL. 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then call kernel_getpeername() which accesses the NULL sock->ops. Above we do a get on the "struct sock", but we needed a get on the "struct socket". Originally, we just held the frwd_lock the entire time but in commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while calling getpeername()") we switched to refcount based because the network layer changed and started taking a mutex in that path, so we could no longer hold the frwd_lock. Instead of trying to maintain multiple refcounts, this just has us use a mutex for accessing the socket in the interface code paths.
- https://git.kernel.org/stable/c/0a0b861fce2657ba08ec356a74346b37ca4b2008
- https://git.kernel.org/stable/c/57569c37f0add1b6489e1a1563c71519daf732cf
- https://git.kernel.org/stable/c/884a788f065578bb640382279a83d1df433b13e6
- https://git.kernel.org/stable/c/897dbbc57d71e8a34ec1af8e573a142de457da38
- https://git.kernel.org/stable/c/a26b0658751bb0a3b28386fca715333b104d32a2
Modified: 2026-01-23
CVE-2022-50480
In the Linux kernel, the following vulnerability has been resolved: memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe() The break of for_each_available_child_of_node() needs a corresponding of_node_put() when the reference 'child' is not used anymore. Here we do not need to call of_node_put() in fail path as '!match' means no break. While the of_platform_device_create() will created a new reference by 'child' but it has considered the refcounting.
- https://git.kernel.org/stable/c/44db35ceb94756ba513dcf6b69bf9e949b28469c
- https://git.kernel.org/stable/c/49605dc25e7fb33bf8b671279d4468531da90f89
- https://git.kernel.org/stable/c/566b143aa5112a0c2784e20603778518bb799537
- https://git.kernel.org/stable/c/61b3c876c1cbdb1efd1f52a1f348580e6e14efb6
- https://git.kernel.org/stable/c/b37f4a711e5d4bf3608ccbc6de82b52e92b441a0
- https://git.kernel.org/stable/c/fde46754d5483bc398018bbec3c8ef5c55219e67
Modified: 2026-01-23
CVE-2022-50484
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential memory leaks When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point. Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list.
- https://git.kernel.org/stable/c/0604e5e5537af099ea2f6dfd892afe5c92db8a80
- https://git.kernel.org/stable/c/0672215994e2347a9b4f145e2bc1709b1e01cee3
- https://git.kernel.org/stable/c/28d8d267af5d73f91d7640cbdb4024703256e36c
- https://git.kernel.org/stable/c/46f0aed47673e275d682af60ed26dcc28add8eae
- https://git.kernel.org/stable/c/6382da0828995af87aa8b8bef28cc61aceb4aff3
- https://git.kernel.org/stable/c/988ec0cd0a2643c25c1658f7c33de2e15a5a2e31
- https://git.kernel.org/stable/c/bc1d16d282bca421c6fc31de4b8fd412010f01bd
- https://git.kernel.org/stable/c/e4442410f76d66b9f7e854010bce04853f665324
- https://git.kernel.org/stable/c/faa8c1ed77d0169955b9b3516b714cc5fb512f27
Modified: 2026-03-25
CVE-2022-50489
In the Linux kernel, the following vulnerability has been resolved: drm/mipi-dsi: Detach devices when removing the host Whenever the MIPI-DSI host is unregistered, the code of mipi_dsi_host_unregister() loops over every device currently found on that bus and will unregister it. However, it doesn't detach it from the bus first, which leads to all kind of resource leaks if the host wants to perform some clean up whenever a device is detached.
- https://git.kernel.org/stable/c/262364574b05676d4b9ebde2ddd3588cd2efd8ce
- https://git.kernel.org/stable/c/26c1b4cfe56f040f71a51c92da1f4cac2e3b9455
- https://git.kernel.org/stable/c/353ab1c13fdd6e524edde780235a8ce9b892c81c
- https://git.kernel.org/stable/c/45120fa5e522d444e3fc1c5a9afc5d53eed91d00
- https://git.kernel.org/stable/c/668a8f17b5290d04ef7343636a5588a0692731a1
- https://git.kernel.org/stable/c/6fc2cd40db1969ba372ce9536dcfcdb87271eac4
- https://git.kernel.org/stable/c/8242167cfc83dd7e4c96f44b45f108db9bb88146
- https://git.kernel.org/stable/c/95ae458209f5a556bba98aff872f933694914eb7
- https://git.kernel.org/stable/c/c202cda08cd5693645d4990ad1eb2e8068a884ec
Modified: 2026-01-23
CVE-2022-50494
In the Linux kernel, the following vulnerability has been resolved:
thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash
When CPU 0 is offline and intel_powerclamp is used to inject
idle, it generates kernel BUG:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687
caller is debug_smp_processor_id+0x17/0x20
CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57
Call Trace:
- https://git.kernel.org/stable/c/0f91f66c568b316b19cb042cf50584467b3bdff4
- https://git.kernel.org/stable/c/3e799e815097febbcb81b472285be824f5d089f9
- https://git.kernel.org/stable/c/418fae0700e85a498062424f8656435c32cdb200
- https://git.kernel.org/stable/c/513943bf879d45005213e6f5cfb7d9e9943f589f
- https://git.kernel.org/stable/c/5614908434451aafbf9b24cb5247cf1d21269f76
- https://git.kernel.org/stable/c/5a646c38f648185ee2c62f2a19da3c6f04e27612
- https://git.kernel.org/stable/c/68b99e94a4a2db6ba9b31fe0485e057b9354a640
- https://git.kernel.org/stable/c/6904727db0eb62fb0c2dce1cf331c341d97ee4b7
- https://git.kernel.org/stable/c/6e2a347b304224b2aeb1c0ea000d1cf8a02cc592
Modified: 2026-03-17
CVE-2022-50512
In the Linux kernel, the following vulnerability has been resolved: ext4: fix potential memory leak in ext4_fc_record_regions() As krealloc may return NULL, in this case 'state->fc_regions' may not be freed by krealloc, but 'state->fc_regions' already set NULL. Then will lead to 'state->fc_regions' memory leak.
- https://git.kernel.org/stable/c/2cfb769d60a2a57eb3566765428b6131cd16dcfe
- https://git.kernel.org/stable/c/417b0455a0b6d0f60a2930592731d1f8340e24be
- https://git.kernel.org/stable/c/518566e71ad86b7c2f1bf6d9caee9588bb7ac158
- https://git.kernel.org/stable/c/7069d105c1f15c442b68af43f7fde784f3126739
- https://git.kernel.org/stable/c/a4058b869e6c5e517c79e30532a350d0f3115c3e
Modified: 2026-03-17
CVE-2022-50513
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv() In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocated in failure, then `pcmdpriv->cmd_allocated_buf` will be not properly released. Besides, considering there are only two error paths and the first one can directly return, so we do not need implicitly jump to the `exit` tag to execute the error handler. So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the error path to release the resource and simplified the return logic of rtw_init_cmd_priv(). As there is no proper device to test with, no runtime testing was performed.
- https://git.kernel.org/stable/c/39bef9c6a91bbb790d04c1347cfeae584541fb6a
- https://git.kernel.org/stable/c/708056fba733a73d926772ea4ce9a42d240345da
- https://git.kernel.org/stable/c/8db6ca84eee0ac258706f3fca54f7c021cb159ef
- https://git.kernel.org/stable/c/a5be64ff6d21f7805a91e6d81f53fc19cd9f0fae
- https://git.kernel.org/stable/c/e5d8f05edb36fc4ab15beec62cb6ab62f5a60fe2
- https://git.kernel.org/stable/c/e6cc39db24a63f68314473621020ed8cad7be423
Modified: 2026-03-17
CVE-2022-50519
In the Linux kernel, the following vulnerability has been resolved: nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failure If creation or finalization of a checkpoint fails due to anomalies in the checkpoint metadata on disk, a kernel warning is generated. This patch replaces the WARN_ONs by nilfs_error, so that a kernel, booted with panic_on_warn, does not panic. A nilfs_error is appropriate here to handle the abnormal filesystem condition. This also replaces the detected error codes with an I/O error so that neither of the internal error codes is returned to callers.
- https://git.kernel.org/stable/c/090fcfb6edeb9367a915b2749e2bd1f8b48d8898
- https://git.kernel.org/stable/c/259c0f68168ac6a598db3486597b10e74d625db0
- https://git.kernel.org/stable/c/5c0776b5bc31de7cd28afb558fae37a20f33602e
- https://git.kernel.org/stable/c/723ac751208f6d6540191689cfbf6c77135a7a1b
- https://git.kernel.org/stable/c/8a18fdc5ae8e6d7ac33c6ee0a2e5f9f1414ef412
- https://git.kernel.org/stable/c/ae16440c44ae2acda6d72aff9d74eccf8967dae5
- https://git.kernel.org/stable/c/b63026b5e13040cd5afa11769dd0d9e1504b031a
- https://git.kernel.org/stable/c/bf98be80cbe3b4e6c86c36ed00457389aca3eb15
- https://git.kernel.org/stable/c/c0c3d3d3ea41cb5228ee90568bb953f9a56c3227
Modified: 2026-02-26
CVE-2022-50544
In the Linux kernel, the following vulnerability has been resolved: usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info() xhci_alloc_stream_info() allocates stream context array for stream_info ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs, stream_info->stream_ctx_array is not released, which will lead to a memory leak. We can fix it by releasing the stream_info->stream_ctx_array with xhci_free_stream_ctx() on the error path to avoid the potential memory leak.
- https://git.kernel.org/stable/c/782c873f8e7686f5b3c47e8b099f7e08c3dd1fdc
- https://git.kernel.org/stable/c/7e271f42a5cc3768cd2622b929ba66859ae21f97
- https://git.kernel.org/stable/c/7fc6bab3413e6a42bb1264ff7c9149808c93a4c7
- https://git.kernel.org/stable/c/91271a3e772e180bbb8afb114c72fd294a02f93d
- https://git.kernel.org/stable/c/9fa81cbd2dd300aa8fe9bac70e068b9a11cbb144
- https://git.kernel.org/stable/c/a40ad475236022f3432880e3091c380e46e71a71
- https://git.kernel.org/stable/c/ddab9fe76296840aad686c66888a9c1dfdbff5ff
- https://git.kernel.org/stable/c/e702de2f5c893bf2cdb0152191f99a6ad1411823
- https://git.kernel.org/stable/c/fcd594da0b5955119d9707e4e0a8d0fb1c969101
Closed bugs
Модуль amdgpu собран без поддержки видеокарт Southern Islands
