ALT-BU-2022-7031-20
Branch sisyphus update bulletin.
Closed bugs
gear uses old location for its bash completion
Closed bugs
Падает апплет сети при первом подключении к wi-fi сети
Package kernel-image-un-def updated to version 6.0.8-alt1 for branch sisyphus in task 309820.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2022-06550
Уязвимость функции l2cap_conn_del() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-06564
Уязвимость функции l2cap_reassemble_sdu() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-07074
Уязвимость функций l2cap_connect и l2cap_le_connect_req (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2023-04465
Уязвимость функции tun_napi_alloc_frags() в модуле drivers/net/tun.c драйвера TUN/TAP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-03-18
BDU:2025-01976
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-06318
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10255
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после ее освобождения, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02638
Уязвимость функции make_indexed_dir() в модуле fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02639
Уязвимость функции ext4_ext_migrate() в модуле fs/ext4/migrate.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03639
Уязвимость функции ip_vs_app_net_cleanup() модуля net/netfilter/ipvs/ip_vs_app.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03730
Уязвимость функции piix4_probe() модуля drivers/i2c/busses/i2c-piix4.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03731
Уязвимость функций l2cap_rx_state_recv() и l2cap_rx() модуля net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03732
Уязвимость функций test_no_shared_qgroup() и test_multiple_refs() модуля fs/btrfs/tests/qgroup-tests.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03733
Уязвимость функций prelim_release() и find_parent_nodes() модуля fs/btrfs/backref.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03879
Уязвимость функции read_reply() модуля drivers/infiniband/sw/rxe/rxe_resp.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03916
Уязвимость функций rsm_load_state_32() и rsm_load_state_64() модуля arch/x86/kvm/emulate.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03962
Уязвимость функции smc_init() модуля net/smc/af_smc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03963
Уязвимость функции kvm_xen_init_vcpu() модуля arch/x86/kvm/xen.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03975
Уязвимость функции __mdiobus_register() модуля drivers/net/phy/mdio_bus.c драйвера сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05778
Уязвимость функции cortex_a76_erratum_1463225_debug_handler() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05779
Уязвимость функций test_gen_kprobe/kretprobe_cmd() и test_gen_kprobe_cmd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05780
Уязвимость функций __ip_vs_cleanup_batch() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05782
Уязвимость функции blk_mq_init_allocated_queue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05783
Уязвимость функции xprt_switch sysfs() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05846
Уязвимость компонента ibmvnic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05847
Уязвимость функции mISDN_register_device() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05848
Уязвимость функции red_enqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06050
Уязвимость функции sc_disable() ядра операционных систем Linux, позволяющая нарушителю вызвать сбой ядра
BDU:2026-06051
Уязвимость функции nf_flow_table_free() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06052
Уязвимость функции rcu_barrier() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06053
Уязвимость функции remove() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06054
Уязвимость функции cxl_port_attach_region() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06055
Уязвимость функции unregister_region() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06057
Уязвимость функции devm_cxl_add_region() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2022-3564
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_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 associated identifier of this vulnerability is VDB-211087.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
Modified: 2024-11-21
CVE-2022-3640
A vulnerability, which was classified as critical, was found in Linux Kernel. Affected is the function l2cap_conn_del of the file net/bluetooth/l2cap_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-211944.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
Modified: 2024-11-21
CVE-2022-42896
There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim. We recommend upgrading past commit https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url
Modified: 2025-10-01
CVE-2022-49035
In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case.
- https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c
- https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4
- https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39
- https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a
- https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968964b26c
- https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11
- https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd
- https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c
Modified: 2025-11-10
CVE-2022-49879
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix BUG_ON() when directory entry has invalid rec_len
The rec_len field in the directory entry has to be a multiple of 4. A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().
------------[ cut here ]------------
kernel BUG at fs/ext4/ext4.h:2413!
...
RIP: 0010:make_indexed_dir+0x53f/0x5f0
...
Call Trace:
- https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad
- https://git.kernel.org/stable/c/17a0bc9bd697f75cfdf9b378d5eb2d7409c91340
- https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909
- https://git.kernel.org/stable/c/999cff2b6ce3b45c08abf793bf55534777421327
- https://git.kernel.org/stable/c/ce1ee2c8827fb6493e91acbd50f664cf2a972c3d
Modified: 2025-10-01
CVE-2022-49880
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883
- https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb
- https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b
- https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e
- https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97
- https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20
- https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6
- https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63
Modified: 2025-11-10
CVE-2022-49882
In the Linux kernel, the following vulnerability has been resolved: KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive. Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmu_notifier invalidation due to the cache not being on the list of gfns to invalidate. Note, "active" needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmu_notifier events. If a relevant mmu_notifier event occurs while the cache is "active" but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmu_notifier event with active users and/or kvm_gpc_refresh(). A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND can be exploited to trigger the bug. 1. Deactivate shinfo cache: kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = false gpc->khva = NULL gpc->active = false Result: active = false, valid = false 2. Cause cache refresh: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check return -EWOULDBLOCK because !gpc->valid kvm_xen_set_evtchn_fast return -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = true gpc->khva = not NULL Result: active = false, valid = true 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast read_lock gpc->lock kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO mutex_lock kvm->lock kvm_xen_shared_info_init kvm_gpc_activate gpc->khva = NULL kvm_gpc_check [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pending_bits = shinfo->evtchn_pending CRASH: test_and_set_bit(..., pending_bits)
Modified: 2025-11-10
CVE-2022-49883
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format On 64 bit host, if the guest doesn't have X86_FEATURE_LM, KVM will access 16 gprs to 32-bit smram image, causing out-ouf-bound ram access. On 32 bit host, the rsm_load_state_64/enter_smm_save_state_64 is compiled out, thus access overflow can't happen.
Modified: 2025-11-10
CVE-2022-49884
In the Linux kernel, the following vulnerability has been resolved: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper Move the gfn_to_pfn_cache lock initialization to another helper and call the new helper during VM/vCPU creation. There are race conditions possible due to kvm_gfn_to_pfn_cache_init()'s ability to re-initialize the cache's locks. For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock. (thread 1) | (thread 2) | kvm_xen_set_evtchn_fast | read_lock_irqsave(&gpc->lock, ...) | | kvm_gfn_to_pfn_cache_init | rwlock_init(&gpc->lock) read_unlock_irqrestore(&gpc->lock, ...) | Rename "cache_init" and "cache_destroy" to activate+deactivate to avoid implying that the cache really is destroyed/freed. Note, there more races in the newly named kvm_gpc_activate() that will be addressed separately. [sean: call out that this is a bug fix]
Modified: 2025-10-01
CVE-2022-49885
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.
The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
The following call trace is observed because of this bug:
[ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[ 9.317131] Call Trace:
[ 9.317134]
Modified: 2025-11-10
CVE-2022-49886
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Panic on bad configs that #VE on "private" memory access All normal kernel memory is "TDX private memory". This includes everything from kernel stacks to kernel text. Handling exceptions on arbitrary accesses to kernel memory is essentially impossible because they can happen in horribly nasty places like kernel entry/exit. But, TDX hardware can theoretically _deliver_ a virtualization exception (#VE) on any access to private memory. But, it's not as bad as it sounds. TDX can be configured to never deliver these exceptions on private memory with a "TD attribute" called ATTR_SEPT_VE_DISABLE. The guest has no way to *set* this attribute, but it can check it. Ensure ATTR_SEPT_VE_DISABLE is set in early boot. panic() if it is unset. There is no sane way for Linux to run with this attribute clear so a panic() is appropriate. There's small window during boot before the check where kernel has an early #VE handler. But the handler is only for port I/O and will also panic() as soon as it sees any other #VE, such as a one generated by a private memory access. [ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo(). Add Kirill's tested-by because I made changes since he wrote this. ]
Modified: 2025-10-01
CVE-2022-49887
In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix possible refcount leak in vdec_probe() v4l2_device_unregister need to be called to put the refcount got by v4l2_device_register when vdec_probe fails or vdec_remove is called.
- https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef
- https://git.kernel.org/stable/c/70119756311a0be3b95bec2e1ba714673e90feba
- https://git.kernel.org/stable/c/7718999356234d9cc6a11b4641bb773928f1390f
- https://git.kernel.org/stable/c/be6e22f54623d8a856a4f167b25be73c2ff1ff80
- https://git.kernel.org/stable/c/f96ad391d054bd5c36994f98afd6a12cbb5600bf
Modified: 2025-05-07
CVE-2022-49888
In the Linux kernel, the following vulnerability has been resolved: arm64: entry: avoid kprobe recursion The cortex_a76_erratum_1463225_debug_handler() function is called when handling debug exceptions (and synchronous exceptions from BRK instructions), and so is called when a probed function executes. If the compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it can be probed. If cortex_a76_erratum_1463225_debug_handler() is probed, any debug exception or software breakpoint exception will result in recursive exceptions leading to a stack overflow. This can be triggered with the ftrace multiple_probes selftest, and as per the example splat below. This is a regression caused by commit: 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround") ... which removed the NOKPROBE_SYMBOL() annotation associated with the function. My intent was that cortex_a76_erratum_1463225_debug_handler() would be inlined into its caller, el1_dbg(), which is marked noinstr and cannot be probed. Mark cortex_a76_erratum_1463225_debug_handler() as __always_inline to ensure this. Example splat prior to this patch (with recursive entries elided): | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64_enter_el1_dbg+0x4/0x20 | lr : el1_dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xe4/0x104 | show_stack+0x18/0x4c | dump_stack_lvl+0x64/0x7c | dump_stack+0x18/0x38 | panic+0x14c/0x338 | test_taint+0x0/0x2c | panic_bad_stack+0x104/0x118 | handle_bad_stack+0x34/0x48 | __bad_stack+0x78/0x7c | arm64_enter_el1_dbg+0x4/0x20 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | do_el0_svc+0x0/0x28 | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]--- With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined into el1_dbg(), and el1_dbg() cannot be probed: | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | sh: write error: No such file or directory | # grep -w cortex_a76_errat ---truncated---
Modified: 2025-10-01
CVE-2022-49889
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters() On some machines the number of listed CPUs may be bigger than the actual CPUs that exist. The tracing subsystem allocates a per_cpu directory with access to the per CPU ring buffer via a cpuX file. But to save space, the ring buffer will only allocate buffers for online CPUs, even though the CPU array will be as big as the nr_cpu_ids. With the addition of waking waiters on the ring buffer when closing the file, the ring_buffer_wake_waiters() now needs to make sure that the buffer is allocated (with the irq_work allocated with it) before trying to wake waiters, as it will cause a NULL pointer dereference. While debugging this, I added a NULL check for the buffer itself (which is OK to do), and also NULL pointer checks against buffer->buffers (which is not fine, and will WARN) as well as making sure the CPU number passed in is within the nr_cpu_ids (which is also not fine if it isn't). Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705
Modified: 2025-10-01
CVE-2022-49890
In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks]
- https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603
- https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1
- https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85
- https://git.kernel.org/stable/c/7480aeff0093d8c54377553ec6b31110bea37b4d
- https://git.kernel.org/stable/c/8cf0a1bc12870d148ae830a4ba88cfdf0e879cee
- https://git.kernel.org/stable/c/90577bcc01c4188416a47269f8433f70502abe98
- https://git.kernel.org/stable/c/cdf01c807e974048c43c7fd3ca574f6086a57906
Modified: 2025-10-01
CVE-2022-49891
In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd() test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd(). unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Modified: 2025-05-07
CVE-2022-49892
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]
Modified: 2025-11-10
CVE-2022-49893
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix cxl_region leak, cleanup targets at region delete When a region is deleted any targets that have been previously assigned to that region hold references to it. Trigger those references to drop by detaching all targets at unregister_region() time. Otherwise that region object will leak as userspace has lost the ability to detach targets once region sysfs is torn down.
Modified: 2025-10-01
CVE-2022-49894
In the Linux kernel, the following vulnerability has been resolved:
cxl/region: Fix region HPA ordering validation
Some regions may not have any address space allocated. Skip them when
validating HPA order otherwise a crash like the following may result:
devm_cxl_add_region: cxl_acpi cxl_acpi.0: decoder3.4: created region9
BUG: kernel NULL pointer dereference, address: 0000000000000000
[..]
RIP: 0010:store_targetN+0x655/0x1740 [cxl_core]
[..]
Call Trace:
Modified: 2025-10-01
CVE-2022-49895
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix decoder allocation crash When an intermediate port's decoders have been exhausted by existing regions, and creating a new region with the port in question in it's hierarchical path is attempted, cxl_port_attach_region() fails to find a port decoder (as would be expected), and drops into the failure / cleanup path. However, during cleanup of the region reference, a sanity check attempts to dereference the decoder, which in the above case didn't exist. This causes a NULL pointer dereference BUG. To fix this, refactor the decoder allocation and de-allocation into helper routines, and in this 'free' routine, check that the decoder, @cxld, is valid before attempting any operations on it.
Modified: 2025-10-01
CVE-2022-49896
In the Linux kernel, the following vulnerability has been resolved: cxl/pmem: Fix cxl_pmem_region and cxl_memdev leak When a cxl_nvdimm object goes through a ->remove() event (device physically removed, nvdimm-bridge disabled, or nvdimm device disabled), then any associated regions must also be disabled. As highlighted by the cxl-create-region.sh test [1], a single device may host multiple regions, but the driver was only tracking one region at a time. This leads to a situation where only the last enabled region per nvdimm device is cleaned up properly. Other regions are leaked, and this also causes cxl_memdev reference leaks. Fix the tracking by allowing cxl_nvdimm objects to track multiple region associations.
Modified: 2025-11-10
CVE-2022-49898
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix tree mod log mishandling of reallocated nodes We have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40 Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); This occurs because we replay the nodes in order that they happened, and when we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot, starting at 0. 'n' here is the number of items in this block, which in this case was 1, but we had 2 REMOVE_WHILE_FREEING operations. The actual root cause of this was that we were replaying operations for a block that shouldn't have been replayed. Consider the following sequence of events 1. We have an already modified root, and we do a btrfs_get_tree_mod_seq(). 2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots. 3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node. 4. We modify a new root, and re-allocate the above node to the root node of this other root. The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8 >From here the bug is triggered by the following steps 1. Call btrfs_get_old_root() on the new_root. 2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0. 3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE. 4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e ---truncated---
Modified: 2025-10-01
CVE-2022-49899
In the Linux kernel, the following vulnerability has been resolved: fscrypt: stop using keyrings subsystem for fscrypt_master_key The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support.
Modified: 2025-11-10
CVE-2022-49900
In the Linux kernel, the following vulnerability has been resolved:
i2c: piix4: Fix adapter not be removed in piix4_remove()
In piix4_probe(), the piix4 adapter will be registered in:
piix4_probe()
piix4_add_adapters_sb800() / piix4_add_adapter()
i2c_add_adapter()
Based on the probed device type, piix4_add_adapters_sb800() or single
piix4_add_adapter() will be called.
For the former case, piix4_adapter_count is set as the number of adapters,
while for antoher case it is not set and kept default *zero*.
When piix4 is removed, piix4_remove() removes the adapters added in
piix4_probe(), basing on the piix4_adapter_count value.
Because the count is zero for the single adapter case, the adapter won't
be removed and makes the sources allocated for adapter leaked, such as
the i2c client and device.
These sources can still be accessed by i2c or bus and cause problems.
An easily reproduced case is that if a new adapter is registered, i2c
will get the leaked adapter and try to call smbus_algorithm, which was
already freed:
Triggered by: rmmod i2c_piix4 && modprobe max31730
BUG: unable to handle page fault for address: ffffffffc053d860
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 3752 Comm: modprobe Tainted: G
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core
RSP: 0018:ffff888107477710 EFLAGS: 00000246
...
Modified: 2025-10-01
CVE-2022-49901
In the Linux kernel, the following vulnerability has been resolved: blk-mq: Fix kmemleak in blk_mq_init_allocated_queue There is a kmemleak caused by modprobe null_blk.ko unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 That is because q->ma_ops is set to NULL before blk_release_queue is called. blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q); [1]: blk_mq_alloc_and_init_hctx failed at i != 0. [2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and will be cleaned up in blk_mq_release. [3]: q->nr_hw_queues is 0. [4]: Set q->mq_ops to NULL. [5]: queue_is_mq returns false due to [4]. And blk_mq_release will not be called. The hctxs in q->unused_hctx_list are leaked. To fix it, call blk_release_queue in exception path.
Modified: 2025-10-01
CVE-2022-49902
In the Linux kernel, the following vulnerability has been resolved: block: Fix possible memory leak for rq_wb on add_disk failure kmemleak reported memory leaks in device_add_disk(): kmemleak: 3 new suspected memory leaks unreferenced object 0xffff88800f420800 (size 512): comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s) hex dump (first 32 bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d3662699>] kmalloc_trace+0x26/0x60 [<00000000edc7aadc>] wbt_init+0x50/0x6f0 [<0000000069601d16>] wbt_enable_default+0x157/0x1c0 [<0000000028fc393f>] blk_register_queue+0x2a4/0x420 [<000000007345a042>] device_add_disk+0x6fd/0xe40 [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd] ... It is because the memory allocated in wbt_enable_default() is not released in device_add_disk() error path. Normally, these memory are freed in: del_gendisk() rq_qos_exit() rqos->ops->exit(rqos); wbt_exit() So rq_qos_exit() is called to free the rq_wb memory for wbt_init(). However in the error path of device_add_disk(), only blk_unregister_queue() is called and make rq_wb memory leaked. Add rq_qos_exit() to the error path to fix it.
Modified: 2025-11-11
CVE-2022-49903
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix WARNING in ip6_route_net_exit_late()
During the initialization of ip6_route_net_init_late(), if file
ipv6_route or rt6_stats fails to be created, the initialization is
successful by default. Therefore, the ipv6_route or rt6_stats file
doesn't be found during the remove in ip6_route_net_exit_late(). It
will cause WRNING.
The following is the stack information:
name 'rt6_stats'
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/080589287127838046077904f34d5054ea0f895c
- https://git.kernel.org/stable/c/0ed71af4d017d2bd2cbb8f7254f613a4914def26
- https://git.kernel.org/stable/c/381453770f731f0f43616a1cd4c759b7807a1517
- https://git.kernel.org/stable/c/5dbb47ee89762da433cd8458788d7640c85f1a07
- https://git.kernel.org/stable/c/768b3c745fe5789f2430bdab02f35a9ad1148d97
- https://git.kernel.org/stable/c/83fbf246ced54dadd7b9adc2a16efeff30ba944d
Modified: 2025-10-01
CVE-2022-49904
In the Linux kernel, the following vulnerability has been resolved:
net, neigh: Fix null-ptr-deref in neigh_table_clear()
When IPv6 module gets initialized but hits an error in the middle,
kenel panic with:
KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
CPU: 1 PID: 361 Comm: insmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
RSP: 0018:ffff888012677908 EFLAGS: 00000202
...
Call Trace:
- https://git.kernel.org/stable/c/0d38b4ca6679e72860ff8730e79bb99d0e9fa3b0
- https://git.kernel.org/stable/c/1c89642e7f2b7ecc9635610653f5c2f0276c0051
- https://git.kernel.org/stable/c/2b45d6d0c41cb9593868e476681efb1aae5078a1
- https://git.kernel.org/stable/c/a99a8ec4c62180c889482a2ff6465033e0743458
- https://git.kernel.org/stable/c/b49f6b2f21f543d4dc88fb7b1ec2adccb822f27c
- https://git.kernel.org/stable/c/b736592de2aa53aee2d48d6b129bc0c892007bbe
- https://git.kernel.org/stable/c/f8017317cb0b279b8ab98b0f3901a2e0ac880dad
Modified: 2025-11-11
CVE-2022-49905
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible leaked pernet namespace in smc_init()
In smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called
without any error handling.
If it fails, registering of &smc_net_ops won't be reverted.
And if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted.
This leaves wild ops in subsystem linkedlist and when another module
tries to call register_pernet_operations() it triggers page fault:
BUG: unable to handle page fault for address: fffffbfff81b964c
RIP: 0010:register_pernet_operations+0x1b9/0x5f0
Call Trace:
Modified: 2025-10-01
CVE-2022-49906
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Free rwi on reset success Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed.
Modified: 2025-11-11
CVE-2022-49907
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/20ed01a7b9af6e6a3c33761eebbb710ea6dd49b7
- https://git.kernel.org/stable/c/40e4eb324c59e11fcb927aa46742d28aba6ecb8a
- https://git.kernel.org/stable/c/4954b5359eb141499492fadfab891e28905509e2
- https://git.kernel.org/stable/c/634f066d02bdb22a26da7deb0c7617ab1a65fc9d
- https://git.kernel.org/stable/c/6ce6f8f8f6316da6f92afe7490bc2f0b654d68e0
- https://git.kernel.org/stable/c/7006176a3c863e3e353ce1b8a349ef5bb1b9320e
- https://git.kernel.org/stable/c/985a88bf0b27193522bba7856b1763f428cef19d
- https://git.kernel.org/stable/c/a3fafc974be37319679f36dc4e7cca7db1e02973
Modified: 2025-10-01
CVE-2022-49908
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix memory leak in vhci_write
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810d81ac00 (size 240):
[...]
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
Modified: 2025-11-11
CVE-2022-49910
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
- https://git.kernel.org/stable/c/03af22e23b96fb7ef75fb7885407ef457e8b403d
- https://git.kernel.org/stable/c/3aff8aaca4e36dc8b17eaa011684881a80238966
- https://git.kernel.org/stable/c/4cd094fd5d872862ca278e15b9b51b07e915ef3f
- https://git.kernel.org/stable/c/6c7407bfbeafc80a04e6eaedcf34d378532a04f2
- https://git.kernel.org/stable/c/8278a87bb1eeea94350d675ef961ee5a03341fde
- https://git.kernel.org/stable/c/9a04161244603f502c6e453913e51edd59cb70c1
- https://git.kernel.org/stable/c/cb1c012099ef5904cd468bdb8d6fcdfdd9bcb569
- https://git.kernel.org/stable/c/dc30e05bb18852303084430c03ca76e69257d9ea
Modified: 2025-11-11
CVE-2022-49911
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: enforce documented limit to prevent allocating huge memory
Daniel Xu reported that the hash:net,iface type of the ipset subsystem does
not limit adding the same network with different interfaces to a set, which
can lead to huge memory usage or allocation failure.
The quick reproducer is
$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0
$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done
The backtrace when vmalloc fails:
[Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages
<...>
[Tue Oct 25 00:13:08 2022] Call Trace:
[Tue Oct 25 00:13:08 2022]
Modified: 2025-11-12
CVE-2022-49912
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ulist leaks in error paths of qgroup self tests In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests, if we fail to add the tree ref, remove the extent item or remove the extent ref, we are returning from the test function without freeing the "old_roots" ulist that was allocated by the previous calls to btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
- https://git.kernel.org/stable/c/0a0dead4ad1a2e2a9bdf133ef45111d7c8daef84
- https://git.kernel.org/stable/c/203204798831c35d855ecc6417d98267d2d2184b
- https://git.kernel.org/stable/c/3f58283d83a588ff5da62fc150de19e798ed2ec2
- https://git.kernel.org/stable/c/5d1a47ebf84540e40b5b43fc21aef0d6c0f627d9
- https://git.kernel.org/stable/c/d37de92b38932d40e4a251e876cc388f9aee5f42
- https://git.kernel.org/stable/c/d81370396025cf63a7a1b5f8bb25a3479203b2ca
- https://git.kernel.org/stable/c/da7003434bcab0ae9aba3f2c003e734cae093326
- https://git.kernel.org/stable/c/f46ea5fa3320dca4fe0c0926b49a5f14cb85de62
Modified: 2025-11-12
CVE-2022-49913
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at find_parent_nodes() During backref walking, at find_parent_nodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolve_indirect_refs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to the refs ulist passed as argument to find_parent_nodes(). Since they were not yet added to the refs ulist and prelim_release() does not free the lists, on error the caller can only free the lists attached to the refs that were added to the refs ulist, all the remaining refs get their inode lists never freed, therefore leaking their memory. Fix this by having prelim_release() always free any attached inode list to each ref found in the rbtree, and have find_parent_nodes() set the ref's inode list to NULL once it transfers ownership of the inode list to a ref added to the refs ulist passed to find_parent_nodes().
- https://git.kernel.org/stable/c/222a3d533027b9492d5b7f5ecdc01a90f57bb5a9
- https://git.kernel.org/stable/c/61e06128113711df0534c404fb6bb528eb7d2332
- https://git.kernel.org/stable/c/6a6731a0df8c47ecc703bd7bb73459df767051e0
- https://git.kernel.org/stable/c/83ea8c5b54d452a5769e605e3c5c687e8ca06d89
- https://git.kernel.org/stable/c/92876eec382a0f19f33d09d2c939e9ca49038ae5
Modified: 2025-11-12
CVE-2022-49914
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the unodes. Fix this by calling free_leaf_list() instead of ulist_free() when we exit from resolve_indirect_refs(). The static function free_leaf_list() is moved up for this to be possible and it's slightly simplified by removing unnecessary code.
- https://git.kernel.org/stable/c/2c0329406bb28109c07c6e23e5e3e0fa618a95d7
- https://git.kernel.org/stable/c/396515db923ad5cbeb179d6b88927870b4cbebb7
- https://git.kernel.org/stable/c/5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1
- https://git.kernel.org/stable/c/6ba3479f9e96b9ad460c7e77abc26dd16e5dec4f
- https://git.kernel.org/stable/c/a52e24c7fcc3c5ce3588a14e3663c00868d36623
- https://git.kernel.org/stable/c/b1dc9019bb5f89abae85645de1a2dd4830c1f8e9
- https://git.kernel.org/stable/c/cded2c89774b99b67c98147ae103ea878c92a206
Modified: 2025-10-01
CVE-2022-49915
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release().
- https://git.kernel.org/stable/c/029d5b7688a2f3a86f2a3be5a6ba9cc968c80e41
- https://git.kernel.org/stable/c/080aabfb29b2ee9cbb8894a1d039651943d3773e
- https://git.kernel.org/stable/c/0d4e91efcaee081e919b3c50e875ecbb84290e41
- https://git.kernel.org/stable/c/2ff6b669523d3b3d253a044fa9636a67d0694995
- https://git.kernel.org/stable/c/a636fc5a7cabd05699b5692ad838c2c7a3abec7b
- https://git.kernel.org/stable/c/d1d1aede313eb2b9a84afd60ff6cfb7c33631e0e
- https://git.kernel.org/stable/c/e77d213843e67b4373285712699b692f9c743f61
- https://git.kernel.org/stable/c/e7d1d4d9ac0dfa40be4c2c8abd0731659869b297
Modified: 2025-10-01
CVE-2022-49916
In the Linux kernel, the following vulnerability has been resolved:
rose: Fix NULL pointer dereference in rose_send_frame()
The syzkaller reported an issue:
KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: rcu_gp srcu_invoke_callbacks
RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
Call Trace:
- https://git.kernel.org/stable/c/01b9c68c121847d05a4ccef68244dadf82bfa331
- https://git.kernel.org/stable/c/3e2129c67daca21043a26575108f6286c85e71f6
- https://git.kernel.org/stable/c/5b46adfbee1e429f33b10a88d6c00fa88f3d6c77
- https://git.kernel.org/stable/c/a601e5eded33bb88b8a42743db8fef3ad41dd97e
- https://git.kernel.org/stable/c/b13be5e852b03f376058027e462fad4230240891
- https://git.kernel.org/stable/c/bbc03d74e641e824754443b908454ca9e203773e
- https://git.kernel.org/stable/c/e97c089d7a49f67027395ddf70bf327eeac2611e
- https://git.kernel.org/stable/c/f06186e5271b980bac03f5c97276ed0146ddc9b0
Modified: 2025-11-12
CVE-2022-49917
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in ip_vs_app_net_cleanup()
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/06d7596d18725f1a93cf817662d36050e5afb989
- https://git.kernel.org/stable/c/2c8d81bdb2684d53d6cedad7410ba4cf9090e343
- https://git.kernel.org/stable/c/5663ed63adb9619c98ab7479aa4606fa9b7a548c
- https://git.kernel.org/stable/c/8457a00c981fe1a799ce34123908856b0f5973b8
- https://git.kernel.org/stable/c/97f872b00937f2689bff2dab4ad9ed259482840f
- https://git.kernel.org/stable/c/adc76740ccd52e4a1d910767cd1223e134a7078b
Modified: 2025-11-12
CVE-2022-49918
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in __ip_vs_cleanup_batch()
During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
or ip_vs_conn_sync fails to be created, the initialization is successful
by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
be found during the remove.
The following is the stack information:
name 'ip_vs_conn_sync'
WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/3d00c6a0da8ddcf75213e004765e4a42acc71d5d
- https://git.kernel.org/stable/c/5ee2d6b726b0ce339e36569e5849692f4cf4595e
- https://git.kernel.org/stable/c/7effc4ce3d1434ce6ff286866585a6e905fdbfc1
- https://git.kernel.org/stable/c/931f56d59c854263b32075bfac56fdb3b1598d1b
- https://git.kernel.org/stable/c/e724220b826e008764309d2a1f55a9434a4e1530
- https://git.kernel.org/stable/c/f08ee2aa24c076f81d84e26e213d8c6f4efd9f50
Modified: 2025-10-01
CVE-2022-49919
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flow rule object from commit path No need to postpone this to the commit release path, since no packets are walking over this object, this is accessed from control plane only. This helped uncovered UAF triggered by races with the netlink notifier.
- https://git.kernel.org/stable/c/26b5934ff4194e13196bedcba373cd4915071d0e
- https://git.kernel.org/stable/c/4ab6f96444e936f5e4a936d5c0bc948144bcded3
- https://git.kernel.org/stable/c/6044791b7be707fd0e709f26e961a446424e5051
- https://git.kernel.org/stable/c/74fd5839467054cd9c4d050614d3ee8788386171
- https://git.kernel.org/stable/c/b2d7a92aff0fbd93c29d2aa6451fb99f050e2c4e
Modified: 2025-10-01
CVE-2022-49920
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: netlink notifier might race to release objects commit release path is invoked via call_rcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path. Call rcu_barrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty.
Modified: 2025-10-01
CVE-2022-49921
In the Linux kernel, the following vulnerability has been resolved: net: sched: Fix use after free in red_enqueue() We can't use "skb" again after passing it to qdisc_enqueue(). This is basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb len before calling child enqueue").
- https://git.kernel.org/stable/c/170e5317042c302777ed6d59fdb84af9b0219d4e
- https://git.kernel.org/stable/c/52e0429471976785c155bfbf51d80990c6cd46e2
- https://git.kernel.org/stable/c/5960b9081baca85cc7dcb14aec1de85999ea9d36
- https://git.kernel.org/stable/c/795afe0b9bb6c915f0299a8e309936519be01619
- https://git.kernel.org/stable/c/8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9
- https://git.kernel.org/stable/c/a238cdcf2bdc72207c74375fc8be13ee549ca9db
- https://git.kernel.org/stable/c/e877f8fa49fbccc63cb2df2e9179bddc695b825a
- https://git.kernel.org/stable/c/fc4b50adb400ee5ec527a04073174e8e73a139fa
Modified: 2025-10-01
CVE-2022-49922
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds.
- https://git.kernel.org/stable/c/52438e734c1566f5e2bcd9a065d2d65e306c0555
- https://git.kernel.org/stable/c/5dfdac5e3f8db5f4445228c44f64091045644a3b
- https://git.kernel.org/stable/c/825656ae61e73ddc05f585e6258d284c87064b10
- https://git.kernel.org/stable/c/92a1df9c6da20c02cf9872f8b025a66ddb307aeb
- https://git.kernel.org/stable/c/93d904a734a74c54d945a9884b4962977f1176cd
- https://git.kernel.org/stable/c/c8e7d4a1166f063703955f1b2e765a6db5bf1771
- https://git.kernel.org/stable/c/dd0ee55ead91fbb16889dbe7ff0b0f7c9e4e849d
- https://git.kernel.org/stable/c/f30060efcf18883748a0541aa41acef183cd9c0e
Modified: 2025-10-01
CVE-2022-49923
In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds.
Modified: 2025-10-01
CVE-2022-49924
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished.
Modified: 2025-10-01
CVE-2022-49925
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
- https://git.kernel.org/stable/c/07c0d131cc0fe1f3981a42958fc52d573d303d89
- https://git.kernel.org/stable/c/6b3d5dcb12347f3518308c2c9d2cf72453a3e1e5
- https://git.kernel.org/stable/c/ab817f75e5e0fa58d9be0825da6a7b7d8a1fa1d9
- https://git.kernel.org/stable/c/af8fb5a0600e9ae29950e9422a032c3c22649ee5
- https://git.kernel.org/stable/c/d360e875c011a005628525bf290322058927e7dc
Modified: 2025-10-01
CVE-2022-49926
In the Linux kernel, the following vulnerability has been resolved: net: dsa: Fix possible memory leaks in dsa_loop_init() kmemleak reported memory leaks in dsa_loop_init(): kmemleak: 12 new suspected memory leaks unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ... There are two reasons for memleak in dsa_loop_init(). First, fixed_phy_register() create and register phy_device: fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove() But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked. Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs. Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.
- https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e
- https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254
- https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50
- https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3
- https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7
- https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f
- https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c
Modified: 2025-10-01
CVE-2022-49927
In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d
- https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67
- https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593
- https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c
- https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d
- https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127
- https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb
- https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401
Modified: 2025-10-01
CVE-2022-49928
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed
There is a null-ptr-deref when xps sysfs alloc failed:
BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0
Read of size 8 at addr 0000000000000030 by task gssproxy/457
CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9
Call Trace:
Modified: 2025-11-12
CVE-2022-49929
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix mr leak in RESPST_ERR_RNR rxe_recheck_mr() will increase mr's ref_cnt, so we should call rxe_put(mr) to drop mr's ref_cnt in RESPST_ERR_RNR to avoid below warning: WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe] ... Call Trace: rxe_dereg_mr+0x4c/0x60 [rdma_rxe] ib_dereg_mr_user+0xa8/0x200 [ib_core] ib_mr_pool_destroy+0x77/0xb0 [ib_core] nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma] nvme_rdma_free_queue+0x40/0x50 [nvme_rdma] nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma] nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma] process_one_work+0x582/0xa40 ? pwq_dec_nr_in_flight+0x100/0x100 ? rwlock_bug.part.0+0x60/0x60 worker_thread+0x2a9/0x700 ? process_one_work+0xa40/0xa40 kthread+0x168/0x1a0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Modified: 2025-10-01
CVE-2022-49930
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix NULL pointer problem in free_mr_init() Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL pointer. It should be init mutex_init() first before use the lock. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __mutex_lock.constprop.0+0xd0/0x5c0 __mutex_lock_slowpath+0x1c/0x2c mutex_lock+0x44/0x50 free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2] hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2] hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2] ib_dereg_mr_user+0x54/0x124 uverbs_free_mr+0x24/0x30 destroy_hw_idr_uobject+0x38/0x74 uverbs_destroy_uobject+0x48/0x1c4 uobj_destroy+0x74/0xcc ib_uverbs_cmd_verbs+0x368/0xbb0 ib_uverbs_ioctl+0xec/0x1a4 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x190 do_el0_svc+0x30/0x90 el0_svc+0x2c/0xb4 el0t_64_sync_handler+0x1a4/0x1b0 el0t_64_sync+0x19c/0x1a0
Modified: 2025-10-01
CVE-2022-49931
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list.
- https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55
- https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e
- https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0
- https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c
- https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926
Modified: 2024-11-21
CVE-2023-3812
An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
Modified: 2025-04-01
CVE-2023-52999
In the Linux kernel, the following vulnerability has been resolved:
net: fix UaF in netns ops registration error path
If net_assign_generic() fails, the current error path in ops_init() tries
to clear the gen pointer slot. Anyway, in such error path, the gen pointer
itself has not been modified yet, and the existing and accessed one is
smaller than the accessed index, causing an out-of-bounds error:
BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320
Write of size 8 at addr ffff888109124978 by task modprobe/1018
CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/12075708f2e77ee6a9f8bb2cf512c38be3099794
- https://git.kernel.org/stable/c/66689a72ba73575e76d4f6a8748d3fa2690ec1c4
- https://git.kernel.org/stable/c/71ab9c3e2253619136c31c89dbb2c69305cc89b1
- https://git.kernel.org/stable/c/ad0dfe9bcf0d78e699c7efb64c90ed062dc48bea
- https://git.kernel.org/stable/c/d4c008f3b7f7d4ffd311eb2dae5e75b3cbddacd0
- https://git.kernel.org/stable/c/ddd49cbbd4c1ceb38032018b589b44208e54f55e
Package kernel-image-std-def updated to version 5.15.78-alt1 for branch sisyphus in task 309821.
Closed vulnerabilities
Modified: 2024-09-30
BDU:2022-06564
Уязвимость функции l2cap_reassemble_sdu() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-07074
Уязвимость функций l2cap_connect и l2cap_le_connect_req (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-01-29
BDU:2023-00946
Уязвимость функции follow_page_pte файла mm/gup.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или получить несанкционированный доступ к защищаемой информации
Modified: 2026-01-20
BDU:2023-04465
Уязвимость функции tun_napi_alloc_frags() в модуле drivers/net/tun.c драйвера TUN/TAP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-03-18
BDU:2025-01976
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10255
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после ее освобождения, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02638
Уязвимость функции make_indexed_dir() в модуле fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02639
Уязвимость функции ext4_ext_migrate() в модуле fs/ext4/migrate.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03639
Уязвимость функции ip_vs_app_net_cleanup() модуля net/netfilter/ipvs/ip_vs_app.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03730
Уязвимость функции piix4_probe() модуля drivers/i2c/busses/i2c-piix4.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03731
Уязвимость функций l2cap_rx_state_recv() и l2cap_rx() модуля net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03732
Уязвимость функций test_no_shared_qgroup() и test_multiple_refs() модуля fs/btrfs/tests/qgroup-tests.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03733
Уязвимость функций prelim_release() и find_parent_nodes() модуля fs/btrfs/backref.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03939
Уязвимость функции __unset_online() модуля drivers/s390/cio/css.c драйвера платформы S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03962
Уязвимость функции smc_init() модуля net/smc/af_smc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03975
Уязвимость функции __mdiobus_register() модуля drivers/net/phy/mdio_bus.c драйвера сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05778
Уязвимость функции cortex_a76_erratum_1463225_debug_handler() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05779
Уязвимость функций test_gen_kprobe/kretprobe_cmd() и test_gen_kprobe_cmd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05780
Уязвимость функций __ip_vs_cleanup_batch() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05783
Уязвимость функции xprt_switch sysfs() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05846
Уязвимость компонента ibmvnic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05847
Уязвимость функции mISDN_register_device() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05848
Уязвимость функции red_enqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06050
Уязвимость функции sc_disable() ядра операционных систем Linux, позволяющая нарушителю вызвать сбой ядра
BDU:2026-06051
Уязвимость функции nf_flow_table_free() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06052
Уязвимость функции rcu_barrier() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
Modified: 2024-11-21
CVE-2022-3564
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_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 associated identifier of this vulnerability is VDB-211087.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
Modified: 2024-11-21
CVE-2022-3623
A vulnerability was found in Linux Kernel. It has been declared as problematic. Affected by this vulnerability is the function follow_page_pte of the file mm/gup.c of the component BPF. The manipulation leads to race condition. The attack can be launched remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-211921 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://vuldb.com/?id.211921
- https://www.debian.org/security/2023/dsa-5324
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://vuldb.com/?id.211921
- https://www.debian.org/security/2023/dsa-5324
Modified: 2024-11-21
CVE-2022-42896
There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim. We recommend upgrading past commit https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url
Modified: 2025-10-01
CVE-2022-49035
In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case.
- https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c
- https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4
- https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39
- https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a
- https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968964b26c
- https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11
- https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd
- https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c
Modified: 2025-11-10
CVE-2022-49879
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix BUG_ON() when directory entry has invalid rec_len
The rec_len field in the directory entry has to be a multiple of 4. A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().
------------[ cut here ]------------
kernel BUG at fs/ext4/ext4.h:2413!
...
RIP: 0010:make_indexed_dir+0x53f/0x5f0
...
Call Trace:
- https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad
- https://git.kernel.org/stable/c/17a0bc9bd697f75cfdf9b378d5eb2d7409c91340
- https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909
- https://git.kernel.org/stable/c/999cff2b6ce3b45c08abf793bf55534777421327
- https://git.kernel.org/stable/c/ce1ee2c8827fb6493e91acbd50f664cf2a972c3d
Modified: 2025-10-01
CVE-2022-49880
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883
- https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb
- https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b
- https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e
- https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97
- https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20
- https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6
- https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63
Modified: 2025-10-01
CVE-2022-49885
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.
The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
The following call trace is observed because of this bug:
[ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[ 9.317131] Call Trace:
[ 9.317134]
Modified: 2025-10-01
CVE-2022-49887
In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix possible refcount leak in vdec_probe() v4l2_device_unregister need to be called to put the refcount got by v4l2_device_register when vdec_probe fails or vdec_remove is called.
- https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef
- https://git.kernel.org/stable/c/70119756311a0be3b95bec2e1ba714673e90feba
- https://git.kernel.org/stable/c/7718999356234d9cc6a11b4641bb773928f1390f
- https://git.kernel.org/stable/c/be6e22f54623d8a856a4f167b25be73c2ff1ff80
- https://git.kernel.org/stable/c/f96ad391d054bd5c36994f98afd6a12cbb5600bf
Modified: 2025-05-07
CVE-2022-49888
In the Linux kernel, the following vulnerability has been resolved: arm64: entry: avoid kprobe recursion The cortex_a76_erratum_1463225_debug_handler() function is called when handling debug exceptions (and synchronous exceptions from BRK instructions), and so is called when a probed function executes. If the compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it can be probed. If cortex_a76_erratum_1463225_debug_handler() is probed, any debug exception or software breakpoint exception will result in recursive exceptions leading to a stack overflow. This can be triggered with the ftrace multiple_probes selftest, and as per the example splat below. This is a regression caused by commit: 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround") ... which removed the NOKPROBE_SYMBOL() annotation associated with the function. My intent was that cortex_a76_erratum_1463225_debug_handler() would be inlined into its caller, el1_dbg(), which is marked noinstr and cannot be probed. Mark cortex_a76_erratum_1463225_debug_handler() as __always_inline to ensure this. Example splat prior to this patch (with recursive entries elided): | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64_enter_el1_dbg+0x4/0x20 | lr : el1_dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xe4/0x104 | show_stack+0x18/0x4c | dump_stack_lvl+0x64/0x7c | dump_stack+0x18/0x38 | panic+0x14c/0x338 | test_taint+0x0/0x2c | panic_bad_stack+0x104/0x118 | handle_bad_stack+0x34/0x48 | __bad_stack+0x78/0x7c | arm64_enter_el1_dbg+0x4/0x20 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | do_el0_svc+0x0/0x28 | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]--- With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined into el1_dbg(), and el1_dbg() cannot be probed: | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | sh: write error: No such file or directory | # grep -w cortex_a76_errat ---truncated---
Modified: 2025-10-01
CVE-2022-49889
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters() On some machines the number of listed CPUs may be bigger than the actual CPUs that exist. The tracing subsystem allocates a per_cpu directory with access to the per CPU ring buffer via a cpuX file. But to save space, the ring buffer will only allocate buffers for online CPUs, even though the CPU array will be as big as the nr_cpu_ids. With the addition of waking waiters on the ring buffer when closing the file, the ring_buffer_wake_waiters() now needs to make sure that the buffer is allocated (with the irq_work allocated with it) before trying to wake waiters, as it will cause a NULL pointer dereference. While debugging this, I added a NULL check for the buffer itself (which is OK to do), and also NULL pointer checks against buffer->buffers (which is not fine, and will WARN) as well as making sure the CPU number passed in is within the nr_cpu_ids (which is also not fine if it isn't). Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705
Modified: 2025-10-01
CVE-2022-49890
In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks]
- https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603
- https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1
- https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85
- https://git.kernel.org/stable/c/7480aeff0093d8c54377553ec6b31110bea37b4d
- https://git.kernel.org/stable/c/8cf0a1bc12870d148ae830a4ba88cfdf0e879cee
- https://git.kernel.org/stable/c/90577bcc01c4188416a47269f8433f70502abe98
- https://git.kernel.org/stable/c/cdf01c807e974048c43c7fd3ca574f6086a57906
Modified: 2025-10-01
CVE-2022-49891
In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd() test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd(). unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Modified: 2025-05-07
CVE-2022-49892
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]
Modified: 2025-11-10
CVE-2022-49898
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix tree mod log mishandling of reallocated nodes We have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40 Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); This occurs because we replay the nodes in order that they happened, and when we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot, starting at 0. 'n' here is the number of items in this block, which in this case was 1, but we had 2 REMOVE_WHILE_FREEING operations. The actual root cause of this was that we were replaying operations for a block that shouldn't have been replayed. Consider the following sequence of events 1. We have an already modified root, and we do a btrfs_get_tree_mod_seq(). 2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots. 3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node. 4. We modify a new root, and re-allocate the above node to the root node of this other root. The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8 >From here the bug is triggered by the following steps 1. Call btrfs_get_old_root() on the new_root. 2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0. 3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE. 4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e ---truncated---
Modified: 2025-10-01
CVE-2022-49899
In the Linux kernel, the following vulnerability has been resolved: fscrypt: stop using keyrings subsystem for fscrypt_master_key The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support.
Modified: 2025-11-10
CVE-2022-49900
In the Linux kernel, the following vulnerability has been resolved:
i2c: piix4: Fix adapter not be removed in piix4_remove()
In piix4_probe(), the piix4 adapter will be registered in:
piix4_probe()
piix4_add_adapters_sb800() / piix4_add_adapter()
i2c_add_adapter()
Based on the probed device type, piix4_add_adapters_sb800() or single
piix4_add_adapter() will be called.
For the former case, piix4_adapter_count is set as the number of adapters,
while for antoher case it is not set and kept default *zero*.
When piix4 is removed, piix4_remove() removes the adapters added in
piix4_probe(), basing on the piix4_adapter_count value.
Because the count is zero for the single adapter case, the adapter won't
be removed and makes the sources allocated for adapter leaked, such as
the i2c client and device.
These sources can still be accessed by i2c or bus and cause problems.
An easily reproduced case is that if a new adapter is registered, i2c
will get the leaked adapter and try to call smbus_algorithm, which was
already freed:
Triggered by: rmmod i2c_piix4 && modprobe max31730
BUG: unable to handle page fault for address: ffffffffc053d860
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 3752 Comm: modprobe Tainted: G
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core
RSP: 0018:ffff888107477710 EFLAGS: 00000246
...
Modified: 2025-10-01
CVE-2022-49902
In the Linux kernel, the following vulnerability has been resolved: block: Fix possible memory leak for rq_wb on add_disk failure kmemleak reported memory leaks in device_add_disk(): kmemleak: 3 new suspected memory leaks unreferenced object 0xffff88800f420800 (size 512): comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s) hex dump (first 32 bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d3662699>] kmalloc_trace+0x26/0x60 [<00000000edc7aadc>] wbt_init+0x50/0x6f0 [<0000000069601d16>] wbt_enable_default+0x157/0x1c0 [<0000000028fc393f>] blk_register_queue+0x2a4/0x420 [<000000007345a042>] device_add_disk+0x6fd/0xe40 [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd] ... It is because the memory allocated in wbt_enable_default() is not released in device_add_disk() error path. Normally, these memory are freed in: del_gendisk() rq_qos_exit() rqos->ops->exit(rqos); wbt_exit() So rq_qos_exit() is called to free the rq_wb memory for wbt_init(). However in the error path of device_add_disk(), only blk_unregister_queue() is called and make rq_wb memory leaked. Add rq_qos_exit() to the error path to fix it.
Modified: 2025-11-11
CVE-2022-49903
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix WARNING in ip6_route_net_exit_late()
During the initialization of ip6_route_net_init_late(), if file
ipv6_route or rt6_stats fails to be created, the initialization is
successful by default. Therefore, the ipv6_route or rt6_stats file
doesn't be found during the remove in ip6_route_net_exit_late(). It
will cause WRNING.
The following is the stack information:
name 'rt6_stats'
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/080589287127838046077904f34d5054ea0f895c
- https://git.kernel.org/stable/c/0ed71af4d017d2bd2cbb8f7254f613a4914def26
- https://git.kernel.org/stable/c/381453770f731f0f43616a1cd4c759b7807a1517
- https://git.kernel.org/stable/c/5dbb47ee89762da433cd8458788d7640c85f1a07
- https://git.kernel.org/stable/c/768b3c745fe5789f2430bdab02f35a9ad1148d97
- https://git.kernel.org/stable/c/83fbf246ced54dadd7b9adc2a16efeff30ba944d
Modified: 2025-10-01
CVE-2022-49904
In the Linux kernel, the following vulnerability has been resolved:
net, neigh: Fix null-ptr-deref in neigh_table_clear()
When IPv6 module gets initialized but hits an error in the middle,
kenel panic with:
KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
CPU: 1 PID: 361 Comm: insmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
RSP: 0018:ffff888012677908 EFLAGS: 00000202
...
Call Trace:
- https://git.kernel.org/stable/c/0d38b4ca6679e72860ff8730e79bb99d0e9fa3b0
- https://git.kernel.org/stable/c/1c89642e7f2b7ecc9635610653f5c2f0276c0051
- https://git.kernel.org/stable/c/2b45d6d0c41cb9593868e476681efb1aae5078a1
- https://git.kernel.org/stable/c/a99a8ec4c62180c889482a2ff6465033e0743458
- https://git.kernel.org/stable/c/b49f6b2f21f543d4dc88fb7b1ec2adccb822f27c
- https://git.kernel.org/stable/c/b736592de2aa53aee2d48d6b129bc0c892007bbe
- https://git.kernel.org/stable/c/f8017317cb0b279b8ab98b0f3901a2e0ac880dad
Modified: 2025-11-11
CVE-2022-49905
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible leaked pernet namespace in smc_init()
In smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called
without any error handling.
If it fails, registering of &smc_net_ops won't be reverted.
And if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted.
This leaves wild ops in subsystem linkedlist and when another module
tries to call register_pernet_operations() it triggers page fault:
BUG: unable to handle page fault for address: fffffbfff81b964c
RIP: 0010:register_pernet_operations+0x1b9/0x5f0
Call Trace:
Modified: 2025-10-01
CVE-2022-49906
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Free rwi on reset success Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed.
Modified: 2025-11-11
CVE-2022-49907
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/20ed01a7b9af6e6a3c33761eebbb710ea6dd49b7
- https://git.kernel.org/stable/c/40e4eb324c59e11fcb927aa46742d28aba6ecb8a
- https://git.kernel.org/stable/c/4954b5359eb141499492fadfab891e28905509e2
- https://git.kernel.org/stable/c/634f066d02bdb22a26da7deb0c7617ab1a65fc9d
- https://git.kernel.org/stable/c/6ce6f8f8f6316da6f92afe7490bc2f0b654d68e0
- https://git.kernel.org/stable/c/7006176a3c863e3e353ce1b8a349ef5bb1b9320e
- https://git.kernel.org/stable/c/985a88bf0b27193522bba7856b1763f428cef19d
- https://git.kernel.org/stable/c/a3fafc974be37319679f36dc4e7cca7db1e02973
Modified: 2025-10-01
CVE-2022-49908
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix memory leak in vhci_write
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810d81ac00 (size 240):
[...]
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
Modified: 2025-11-11
CVE-2022-49910
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
- https://git.kernel.org/stable/c/03af22e23b96fb7ef75fb7885407ef457e8b403d
- https://git.kernel.org/stable/c/3aff8aaca4e36dc8b17eaa011684881a80238966
- https://git.kernel.org/stable/c/4cd094fd5d872862ca278e15b9b51b07e915ef3f
- https://git.kernel.org/stable/c/6c7407bfbeafc80a04e6eaedcf34d378532a04f2
- https://git.kernel.org/stable/c/8278a87bb1eeea94350d675ef961ee5a03341fde
- https://git.kernel.org/stable/c/9a04161244603f502c6e453913e51edd59cb70c1
- https://git.kernel.org/stable/c/cb1c012099ef5904cd468bdb8d6fcdfdd9bcb569
- https://git.kernel.org/stable/c/dc30e05bb18852303084430c03ca76e69257d9ea
Modified: 2025-11-11
CVE-2022-49911
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: enforce documented limit to prevent allocating huge memory
Daniel Xu reported that the hash:net,iface type of the ipset subsystem does
not limit adding the same network with different interfaces to a set, which
can lead to huge memory usage or allocation failure.
The quick reproducer is
$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0
$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done
The backtrace when vmalloc fails:
[Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages
<...>
[Tue Oct 25 00:13:08 2022] Call Trace:
[Tue Oct 25 00:13:08 2022]
Modified: 2025-11-12
CVE-2022-49912
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ulist leaks in error paths of qgroup self tests In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests, if we fail to add the tree ref, remove the extent item or remove the extent ref, we are returning from the test function without freeing the "old_roots" ulist that was allocated by the previous calls to btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
- https://git.kernel.org/stable/c/0a0dead4ad1a2e2a9bdf133ef45111d7c8daef84
- https://git.kernel.org/stable/c/203204798831c35d855ecc6417d98267d2d2184b
- https://git.kernel.org/stable/c/3f58283d83a588ff5da62fc150de19e798ed2ec2
- https://git.kernel.org/stable/c/5d1a47ebf84540e40b5b43fc21aef0d6c0f627d9
- https://git.kernel.org/stable/c/d37de92b38932d40e4a251e876cc388f9aee5f42
- https://git.kernel.org/stable/c/d81370396025cf63a7a1b5f8bb25a3479203b2ca
- https://git.kernel.org/stable/c/da7003434bcab0ae9aba3f2c003e734cae093326
- https://git.kernel.org/stable/c/f46ea5fa3320dca4fe0c0926b49a5f14cb85de62
Modified: 2025-11-12
CVE-2022-49913
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at find_parent_nodes() During backref walking, at find_parent_nodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolve_indirect_refs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to the refs ulist passed as argument to find_parent_nodes(). Since they were not yet added to the refs ulist and prelim_release() does not free the lists, on error the caller can only free the lists attached to the refs that were added to the refs ulist, all the remaining refs get their inode lists never freed, therefore leaking their memory. Fix this by having prelim_release() always free any attached inode list to each ref found in the rbtree, and have find_parent_nodes() set the ref's inode list to NULL once it transfers ownership of the inode list to a ref added to the refs ulist passed to find_parent_nodes().
- https://git.kernel.org/stable/c/222a3d533027b9492d5b7f5ecdc01a90f57bb5a9
- https://git.kernel.org/stable/c/61e06128113711df0534c404fb6bb528eb7d2332
- https://git.kernel.org/stable/c/6a6731a0df8c47ecc703bd7bb73459df767051e0
- https://git.kernel.org/stable/c/83ea8c5b54d452a5769e605e3c5c687e8ca06d89
- https://git.kernel.org/stable/c/92876eec382a0f19f33d09d2c939e9ca49038ae5
Modified: 2025-11-12
CVE-2022-49914
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the unodes. Fix this by calling free_leaf_list() instead of ulist_free() when we exit from resolve_indirect_refs(). The static function free_leaf_list() is moved up for this to be possible and it's slightly simplified by removing unnecessary code.
- https://git.kernel.org/stable/c/2c0329406bb28109c07c6e23e5e3e0fa618a95d7
- https://git.kernel.org/stable/c/396515db923ad5cbeb179d6b88927870b4cbebb7
- https://git.kernel.org/stable/c/5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1
- https://git.kernel.org/stable/c/6ba3479f9e96b9ad460c7e77abc26dd16e5dec4f
- https://git.kernel.org/stable/c/a52e24c7fcc3c5ce3588a14e3663c00868d36623
- https://git.kernel.org/stable/c/b1dc9019bb5f89abae85645de1a2dd4830c1f8e9
- https://git.kernel.org/stable/c/cded2c89774b99b67c98147ae103ea878c92a206
Modified: 2025-10-01
CVE-2022-49915
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release().
- https://git.kernel.org/stable/c/029d5b7688a2f3a86f2a3be5a6ba9cc968c80e41
- https://git.kernel.org/stable/c/080aabfb29b2ee9cbb8894a1d039651943d3773e
- https://git.kernel.org/stable/c/0d4e91efcaee081e919b3c50e875ecbb84290e41
- https://git.kernel.org/stable/c/2ff6b669523d3b3d253a044fa9636a67d0694995
- https://git.kernel.org/stable/c/a636fc5a7cabd05699b5692ad838c2c7a3abec7b
- https://git.kernel.org/stable/c/d1d1aede313eb2b9a84afd60ff6cfb7c33631e0e
- https://git.kernel.org/stable/c/e77d213843e67b4373285712699b692f9c743f61
- https://git.kernel.org/stable/c/e7d1d4d9ac0dfa40be4c2c8abd0731659869b297
Modified: 2025-10-01
CVE-2022-49916
In the Linux kernel, the following vulnerability has been resolved:
rose: Fix NULL pointer dereference in rose_send_frame()
The syzkaller reported an issue:
KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: rcu_gp srcu_invoke_callbacks
RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
Call Trace:
- https://git.kernel.org/stable/c/01b9c68c121847d05a4ccef68244dadf82bfa331
- https://git.kernel.org/stable/c/3e2129c67daca21043a26575108f6286c85e71f6
- https://git.kernel.org/stable/c/5b46adfbee1e429f33b10a88d6c00fa88f3d6c77
- https://git.kernel.org/stable/c/a601e5eded33bb88b8a42743db8fef3ad41dd97e
- https://git.kernel.org/stable/c/b13be5e852b03f376058027e462fad4230240891
- https://git.kernel.org/stable/c/bbc03d74e641e824754443b908454ca9e203773e
- https://git.kernel.org/stable/c/e97c089d7a49f67027395ddf70bf327eeac2611e
- https://git.kernel.org/stable/c/f06186e5271b980bac03f5c97276ed0146ddc9b0
Modified: 2025-11-12
CVE-2022-49917
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in ip_vs_app_net_cleanup()
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/06d7596d18725f1a93cf817662d36050e5afb989
- https://git.kernel.org/stable/c/2c8d81bdb2684d53d6cedad7410ba4cf9090e343
- https://git.kernel.org/stable/c/5663ed63adb9619c98ab7479aa4606fa9b7a548c
- https://git.kernel.org/stable/c/8457a00c981fe1a799ce34123908856b0f5973b8
- https://git.kernel.org/stable/c/97f872b00937f2689bff2dab4ad9ed259482840f
- https://git.kernel.org/stable/c/adc76740ccd52e4a1d910767cd1223e134a7078b
Modified: 2025-11-12
CVE-2022-49918
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in __ip_vs_cleanup_batch()
During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
or ip_vs_conn_sync fails to be created, the initialization is successful
by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
be found during the remove.
The following is the stack information:
name 'ip_vs_conn_sync'
WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/3d00c6a0da8ddcf75213e004765e4a42acc71d5d
- https://git.kernel.org/stable/c/5ee2d6b726b0ce339e36569e5849692f4cf4595e
- https://git.kernel.org/stable/c/7effc4ce3d1434ce6ff286866585a6e905fdbfc1
- https://git.kernel.org/stable/c/931f56d59c854263b32075bfac56fdb3b1598d1b
- https://git.kernel.org/stable/c/e724220b826e008764309d2a1f55a9434a4e1530
- https://git.kernel.org/stable/c/f08ee2aa24c076f81d84e26e213d8c6f4efd9f50
Modified: 2025-10-01
CVE-2022-49919
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flow rule object from commit path No need to postpone this to the commit release path, since no packets are walking over this object, this is accessed from control plane only. This helped uncovered UAF triggered by races with the netlink notifier.
- https://git.kernel.org/stable/c/26b5934ff4194e13196bedcba373cd4915071d0e
- https://git.kernel.org/stable/c/4ab6f96444e936f5e4a936d5c0bc948144bcded3
- https://git.kernel.org/stable/c/6044791b7be707fd0e709f26e961a446424e5051
- https://git.kernel.org/stable/c/74fd5839467054cd9c4d050614d3ee8788386171
- https://git.kernel.org/stable/c/b2d7a92aff0fbd93c29d2aa6451fb99f050e2c4e
Modified: 2025-10-01
CVE-2022-49920
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: netlink notifier might race to release objects commit release path is invoked via call_rcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path. Call rcu_barrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty.
Modified: 2025-10-01
CVE-2022-49921
In the Linux kernel, the following vulnerability has been resolved: net: sched: Fix use after free in red_enqueue() We can't use "skb" again after passing it to qdisc_enqueue(). This is basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb len before calling child enqueue").
- https://git.kernel.org/stable/c/170e5317042c302777ed6d59fdb84af9b0219d4e
- https://git.kernel.org/stable/c/52e0429471976785c155bfbf51d80990c6cd46e2
- https://git.kernel.org/stable/c/5960b9081baca85cc7dcb14aec1de85999ea9d36
- https://git.kernel.org/stable/c/795afe0b9bb6c915f0299a8e309936519be01619
- https://git.kernel.org/stable/c/8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9
- https://git.kernel.org/stable/c/a238cdcf2bdc72207c74375fc8be13ee549ca9db
- https://git.kernel.org/stable/c/e877f8fa49fbccc63cb2df2e9179bddc695b825a
- https://git.kernel.org/stable/c/fc4b50adb400ee5ec527a04073174e8e73a139fa
Modified: 2025-10-01
CVE-2022-49922
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds.
- https://git.kernel.org/stable/c/52438e734c1566f5e2bcd9a065d2d65e306c0555
- https://git.kernel.org/stable/c/5dfdac5e3f8db5f4445228c44f64091045644a3b
- https://git.kernel.org/stable/c/825656ae61e73ddc05f585e6258d284c87064b10
- https://git.kernel.org/stable/c/92a1df9c6da20c02cf9872f8b025a66ddb307aeb
- https://git.kernel.org/stable/c/93d904a734a74c54d945a9884b4962977f1176cd
- https://git.kernel.org/stable/c/c8e7d4a1166f063703955f1b2e765a6db5bf1771
- https://git.kernel.org/stable/c/dd0ee55ead91fbb16889dbe7ff0b0f7c9e4e849d
- https://git.kernel.org/stable/c/f30060efcf18883748a0541aa41acef183cd9c0e
Modified: 2025-10-01
CVE-2022-49923
In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds.
Modified: 2025-10-01
CVE-2022-49924
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished.
Modified: 2025-10-01
CVE-2022-49925
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
- https://git.kernel.org/stable/c/07c0d131cc0fe1f3981a42958fc52d573d303d89
- https://git.kernel.org/stable/c/6b3d5dcb12347f3518308c2c9d2cf72453a3e1e5
- https://git.kernel.org/stable/c/ab817f75e5e0fa58d9be0825da6a7b7d8a1fa1d9
- https://git.kernel.org/stable/c/af8fb5a0600e9ae29950e9422a032c3c22649ee5
- https://git.kernel.org/stable/c/d360e875c011a005628525bf290322058927e7dc
Modified: 2025-10-01
CVE-2022-49926
In the Linux kernel, the following vulnerability has been resolved: net: dsa: Fix possible memory leaks in dsa_loop_init() kmemleak reported memory leaks in dsa_loop_init(): kmemleak: 12 new suspected memory leaks unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ... There are two reasons for memleak in dsa_loop_init(). First, fixed_phy_register() create and register phy_device: fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove() But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked. Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs. Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.
- https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e
- https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254
- https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50
- https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3
- https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7
- https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f
- https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c
Modified: 2025-10-01
CVE-2022-49927
In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d
- https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67
- https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593
- https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c
- https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d
- https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127
- https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb
- https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401
Modified: 2025-10-01
CVE-2022-49928
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed
There is a null-ptr-deref when xps sysfs alloc failed:
BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0
Read of size 8 at addr 0000000000000030 by task gssproxy/457
CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9
Call Trace:
Modified: 2025-10-01
CVE-2022-49931
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list.
- https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55
- https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e
- https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0
- https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c
- https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926
Modified: 2025-12-04
CVE-2022-50307
In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix out-of-bounds access on cio_ignore free The channel-subsystem-driver scans for newly available devices whenever device-IDs are removed from the cio_ignore list using a command such as: echo free >/proc/cio_ignore Since an I/O device scan might interfer with running I/Os, commit 172da89ed0ea ("s390/cio: avoid excessive path-verification requests") introduced an optimization to exclude online devices from the scan. The newly added check for online devices incorrectly assumes that an I/O-subchannel's drvdata points to a struct io_subchannel_private. For devices that are bound to a non-default I/O subchannel driver, such as the vfio_ccw driver, this results in an out-of-bounds read access during each scan. Fix this by changing the scan logic to rely on a driver-independent online indication. For this we can use struct subchannel->config.ena, which is the driver's requested subchannel-enabled state. Since I/Os can only be started on enabled subchannels, this matches the intent of the original optimization of not scanning devices where I/O might be running.
Modified: 2024-11-21
CVE-2023-3812
An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
Closed bugs
без xterm не работает
Package kernel-image-mp updated to version 6.0.8-alt1 for branch sisyphus in task 309869.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2022-06550
Уязвимость функции l2cap_conn_del() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-06564
Уязвимость функции l2cap_reassemble_sdu() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-07074
Уязвимость функций l2cap_connect и l2cap_le_connect_req (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2023-12-12
BDU:2022-07347
Уязвимость компонента drivers/char/pcmcia/scr24x_cs.c ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2026-01-20
BDU:2023-04465
Уязвимость функции tun_napi_alloc_frags() в модуле drivers/net/tun.c драйвера TUN/TAP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
BDU:2023-04895
Уязвимость драйвера PCMCIA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
BDU:2023-04896
Уязвимость драйвера PCMCIA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие
Modified: 2025-03-18
BDU:2025-01976
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10255
Уязвимость ядра операционной системы Linux, связанная с использованием памяти после ее освобождения, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-09
BDU:2025-12806
Уязвимость функции __split_huge_page_tail() в модуле mm/huge_memory.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01285
Уязвимость функции kernfs_remove_by_name_ns() модуля fs/kernfs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-03-04
BDU:2026-02052
Уязвимость функции SMB2_sess_auth_rawntlmssp_negotiate() модуля fs/cifs/smb2pdu.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02177
Уязвимость функции sata_pmp_init_links() в модуле drivers/ata/libata-pmp.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02258
Уязвимость функции ext4_fc_replay_scan() в модуле fs/ext4/fast_commit.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02372
Уязвимость функции msm_dsi_modeset_init() модуля drivers/gpu/drm/msm/dsi/dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02434
Уязвимость функции hnae_ae_register() модуля drivers/net/ethernet/hisilicon/hns/hnae.c драйвера сетевых адаптеров Ethernet Hisilicon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02435
Уязвимость функции sfb_reset() модуля net/sched/sch_sfb.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02638
Уязвимость функции make_indexed_dir() в модуле fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02639
Уязвимость функции ext4_ext_migrate() в модуле fs/ext4/migrate.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03639
Уязвимость функции ip_vs_app_net_cleanup() модуля net/netfilter/ipvs/ip_vs_app.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03730
Уязвимость функции piix4_probe() модуля drivers/i2c/busses/i2c-piix4.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03731
Уязвимость функций l2cap_rx_state_recv() и l2cap_rx() модуля net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03732
Уязвимость функций test_no_shared_qgroup() и test_multiple_refs() модуля fs/btrfs/tests/qgroup-tests.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03733
Уязвимость функций prelim_release() и find_parent_nodes() модуля fs/btrfs/backref.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03767
Уязвимость функции cifs_create() модуля fs/cifs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03775
Уязвимость функции addrconf_init_net() модуля net/ipv6/addrconf.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03828
Уязвимость функции tipc_topsrv_kern_subscr() модуля net/tipc/topsrv.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03838
Уязвимость функции cifs_flock() модуля fs/cifs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03879
Уязвимость функции read_reply() модуля drivers/infiniband/sw/rxe/rxe_resp.c драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03916
Уязвимость функций rsm_load_state_32() и rsm_load_state_64() модуля arch/x86/kvm/emulate.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03938
Уязвимость функции wwan_hwsim_dev_new() модуля drivers/net/wwan/wwan_hwsim.c драйвера сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03939
Уязвимость функции __unset_online() модуля drivers/s390/cio/css.c драйвера платформы S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03940
Уязвимость функции skb_append_pagefrags() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03962
Уязвимость функции smc_init() модуля net/smc/af_smc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03963
Уязвимость функции kvm_xen_init_vcpu() модуля arch/x86/kvm/xen.c подсистемы виртуализации на платформе x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03975
Уязвимость функции __mdiobus_register() модуля drivers/net/phy/mdio_bus.c драйвера сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04052
Уязвимость функции snd_ac97_dev_register() модуля sound/pci/ac97/ac97_codec.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04055
Уязвимость функции i2sbus_add_dev() модуля sound/aoa/soundbus/i2sbus/core.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04093
Уязвимость функции blk_mq_clear_rq_mapping() модуля block/blk-mq.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04383
Уязвимость функции msm_dp_modeset_init() модуля drivers/gpu/drm/msm/dp/dp_display.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05735
Уязвимость функции alloc_huge_page() модуля mm/hugetlb.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05778
Уязвимость функции cortex_a76_erratum_1463225_debug_handler() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05779
Уязвимость функций test_gen_kprobe/kretprobe_cmd() и test_gen_kprobe_cmd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05780
Уязвимость функций __ip_vs_cleanup_batch() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05782
Уязвимость функции blk_mq_init_allocated_queue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05783
Уязвимость функции xprt_switch sysfs() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05846
Уязвимость компонента ibmvnic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05847
Уязвимость функции mISDN_register_device() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05848
Уязвимость функции red_enqueue() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05934
Уязвимость функции sysfb_disable() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05978
Уязвимость функции hinic_init_cmdqs() модуля drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06031
Уязвимость функции alloc_sk_msg() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06050
Уязвимость функции sc_disable() ядра операционных систем Linux, позволяющая нарушителю вызвать сбой ядра
BDU:2026-06051
Уязвимость функции nf_flow_table_free() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06052
Уязвимость функции rcu_barrier() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06053
Уязвимость функции remove() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06054
Уязвимость функции cxl_port_attach_region() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06055
Уязвимость функции unregister_region() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06057
Уязвимость функции devm_cxl_add_region() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06069
Уязвимость функции qcom_cpufreq_probe() в модуле drivers/cpufreq/qcom-cpufreq-nvmem.c драйвера масштабирования частоты ЦП ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06077
Уязвимость функции io_msg_send_fd() в модуле io_uring/msg_ring.c интерфейса асинхронного ввода/вывода ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06081
Уязвимость функции __copy_xstate_to_uabi_buf() в модуле arch/x86/kernel/fpu/xstate.c поддержки платформы x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06084
Уязвимость функции hinic_dbg_get_func_table() в модуле drivers/net/ethernet/huawei/hinic/hinic_debugfs.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06089
Уязвимость функции cake_dequeue() в модуле net/sched/sch_cake.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06092
Уязвимость функции load_elf_binary() в модуле fs/binfmt_elf.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2022-3564
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_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 associated identifier of this vulnerability is VDB-211087.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
Modified: 2024-11-21
CVE-2022-3640
A vulnerability, which was classified as critical, was found in Linux Kernel. Affected is the function l2cap_conn_del of the file net/bluetooth/l2cap_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-211944.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
Modified: 2024-11-21
CVE-2022-42896
There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim. We recommend upgrading past commit https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url
Modified: 2024-11-21
CVE-2022-44032
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4000_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cmm_open() and cm4000_detach().
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/
- https://lore.kernel.org/lkml/20220919040701.GA302806%40ubuntu/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/
- https://lore.kernel.org/lkml/20220919040701.GA302806%40ubuntu/
Modified: 2024-11-21
CVE-2022-44033
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4040_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cm4040_open() and reader_detach().
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/
- https://lore.kernel.org/lkml/20220919040457.GA302681%40ubuntu/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/
- https://lore.kernel.org/lkml/20220919040457.GA302681%40ubuntu/
Modified: 2024-11-21
CVE-2022-44034
An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/scr24x_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between scr24x_open() and scr24x_remove().
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220916050333.GA188358%40ubuntu/
- https://lore.kernel.org/lkml/20220919101825.GA313940%40ubuntu/
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15
- https://lore.kernel.org/lkml/20220916050333.GA188358%40ubuntu/
- https://lore.kernel.org/lkml/20220919101825.GA313940%40ubuntu/
Modified: 2025-10-01
CVE-2022-49035
In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case.
- https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c
- https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4
- https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39
- https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a
- https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968964b26c
- https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11
- https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd
- https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c
Modified: 2025-11-10
CVE-2022-49879
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix BUG_ON() when directory entry has invalid rec_len
The rec_len field in the directory entry has to be a multiple of 4. A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().
------------[ cut here ]------------
kernel BUG at fs/ext4/ext4.h:2413!
...
RIP: 0010:make_indexed_dir+0x53f/0x5f0
...
Call Trace:
- https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad
- https://git.kernel.org/stable/c/17a0bc9bd697f75cfdf9b378d5eb2d7409c91340
- https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909
- https://git.kernel.org/stable/c/999cff2b6ce3b45c08abf793bf55534777421327
- https://git.kernel.org/stable/c/ce1ee2c8827fb6493e91acbd50f664cf2a972c3d
Modified: 2025-10-01
CVE-2022-49880
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883
- https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb
- https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b
- https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e
- https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97
- https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20
- https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6
- https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63
Modified: 2025-11-10
CVE-2022-49882
In the Linux kernel, the following vulnerability has been resolved: KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive. Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmu_notifier invalidation due to the cache not being on the list of gfns to invalidate. Note, "active" needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmu_notifier events. If a relevant mmu_notifier event occurs while the cache is "active" but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmu_notifier event with active users and/or kvm_gpc_refresh(). A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND can be exploited to trigger the bug. 1. Deactivate shinfo cache: kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = false gpc->khva = NULL gpc->active = false Result: active = false, valid = false 2. Cause cache refresh: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check return -EWOULDBLOCK because !gpc->valid kvm_xen_set_evtchn_fast return -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = true gpc->khva = not NULL Result: active = false, valid = true 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast read_lock gpc->lock kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO mutex_lock kvm->lock kvm_xen_shared_info_init kvm_gpc_activate gpc->khva = NULL kvm_gpc_check [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pending_bits = shinfo->evtchn_pending CRASH: test_and_set_bit(..., pending_bits)
Modified: 2025-11-10
CVE-2022-49883
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: smm: number of GPRs in the SMRAM image depends on the image format On 64 bit host, if the guest doesn't have X86_FEATURE_LM, KVM will access 16 gprs to 32-bit smram image, causing out-ouf-bound ram access. On 32 bit host, the rsm_load_state_64/enter_smm_save_state_64 is compiled out, thus access overflow can't happen.
Modified: 2025-11-10
CVE-2022-49884
In the Linux kernel, the following vulnerability has been resolved: KVM: Initialize gfn_to_pfn_cache locks in dedicated helper Move the gfn_to_pfn_cache lock initialization to another helper and call the new helper during VM/vCPU creation. There are race conditions possible due to kvm_gfn_to_pfn_cache_init()'s ability to re-initialize the cache's locks. For example: a race between ioctl(KVM_XEN_HVM_EVTCHN_SEND) and kvm_gfn_to_pfn_cache_init() leads to a corrupted shinfo gpc lock. (thread 1) | (thread 2) | kvm_xen_set_evtchn_fast | read_lock_irqsave(&gpc->lock, ...) | | kvm_gfn_to_pfn_cache_init | rwlock_init(&gpc->lock) read_unlock_irqrestore(&gpc->lock, ...) | Rename "cache_init" and "cache_destroy" to activate+deactivate to avoid implying that the cache really is destroyed/freed. Note, there more races in the newly named kvm_gpc_activate() that will be addressed separately. [sean: call out that this is a bug fix]
Modified: 2025-10-01
CVE-2022-49885
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.
The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
The following call trace is observed because of this bug:
[ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[ 9.317131] Call Trace:
[ 9.317134]
Modified: 2025-11-10
CVE-2022-49886
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Panic on bad configs that #VE on "private" memory access All normal kernel memory is "TDX private memory". This includes everything from kernel stacks to kernel text. Handling exceptions on arbitrary accesses to kernel memory is essentially impossible because they can happen in horribly nasty places like kernel entry/exit. But, TDX hardware can theoretically _deliver_ a virtualization exception (#VE) on any access to private memory. But, it's not as bad as it sounds. TDX can be configured to never deliver these exceptions on private memory with a "TD attribute" called ATTR_SEPT_VE_DISABLE. The guest has no way to *set* this attribute, but it can check it. Ensure ATTR_SEPT_VE_DISABLE is set in early boot. panic() if it is unset. There is no sane way for Linux to run with this attribute clear so a panic() is appropriate. There's small window during boot before the check where kernel has an early #VE handler. But the handler is only for port I/O and will also panic() as soon as it sees any other #VE, such as a one generated by a private memory access. [ dhansen: Rewrite changelog and rebase on new tdx_parse_tdinfo(). Add Kirill's tested-by because I made changes since he wrote this. ]
Modified: 2025-10-01
CVE-2022-49887
In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix possible refcount leak in vdec_probe() v4l2_device_unregister need to be called to put the refcount got by v4l2_device_register when vdec_probe fails or vdec_remove is called.
- https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef
- https://git.kernel.org/stable/c/70119756311a0be3b95bec2e1ba714673e90feba
- https://git.kernel.org/stable/c/7718999356234d9cc6a11b4641bb773928f1390f
- https://git.kernel.org/stable/c/be6e22f54623d8a856a4f167b25be73c2ff1ff80
- https://git.kernel.org/stable/c/f96ad391d054bd5c36994f98afd6a12cbb5600bf
Modified: 2025-05-07
CVE-2022-49888
In the Linux kernel, the following vulnerability has been resolved: arm64: entry: avoid kprobe recursion The cortex_a76_erratum_1463225_debug_handler() function is called when handling debug exceptions (and synchronous exceptions from BRK instructions), and so is called when a probed function executes. If the compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it can be probed. If cortex_a76_erratum_1463225_debug_handler() is probed, any debug exception or software breakpoint exception will result in recursive exceptions leading to a stack overflow. This can be triggered with the ftrace multiple_probes selftest, and as per the example splat below. This is a regression caused by commit: 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround") ... which removed the NOKPROBE_SYMBOL() annotation associated with the function. My intent was that cortex_a76_erratum_1463225_debug_handler() would be inlined into its caller, el1_dbg(), which is marked noinstr and cannot be probed. Mark cortex_a76_erratum_1463225_debug_handler() as __always_inline to ensure this. Example splat prior to this patch (with recursive entries elided): | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64_enter_el1_dbg+0x4/0x20 | lr : el1_dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xe4/0x104 | show_stack+0x18/0x4c | dump_stack_lvl+0x64/0x7c | dump_stack+0x18/0x38 | panic+0x14c/0x338 | test_taint+0x0/0x2c | panic_bad_stack+0x104/0x118 | handle_bad_stack+0x34/0x48 | __bad_stack+0x78/0x7c | arm64_enter_el1_dbg+0x4/0x20 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | do_el0_svc+0x0/0x28 | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]--- With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined into el1_dbg(), and el1_dbg() cannot be probed: | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | sh: write error: No such file or directory | # grep -w cortex_a76_errat ---truncated---
Modified: 2025-10-01
CVE-2022-49889
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Check for NULL cpu_buffer in ring_buffer_wake_waiters() On some machines the number of listed CPUs may be bigger than the actual CPUs that exist. The tracing subsystem allocates a per_cpu directory with access to the per CPU ring buffer via a cpuX file. But to save space, the ring buffer will only allocate buffers for online CPUs, even though the CPU array will be as big as the nr_cpu_ids. With the addition of waking waiters on the ring buffer when closing the file, the ring_buffer_wake_waiters() now needs to make sure that the buffer is allocated (with the irq_work allocated with it) before trying to wake waiters, as it will cause a NULL pointer dereference. While debugging this, I added a NULL check for the buffer itself (which is OK to do), and also NULL pointer checks against buffer->buffers (which is not fine, and will WARN) as well as making sure the CPU number passed in is within the nr_cpu_ids (which is also not fine if it isn't). Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1204705
Modified: 2025-10-01
CVE-2022-49890
In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks]
- https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603
- https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1
- https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85
- https://git.kernel.org/stable/c/7480aeff0093d8c54377553ec6b31110bea37b4d
- https://git.kernel.org/stable/c/8cf0a1bc12870d148ae830a4ba88cfdf0e879cee
- https://git.kernel.org/stable/c/90577bcc01c4188416a47269f8433f70502abe98
- https://git.kernel.org/stable/c/cdf01c807e974048c43c7fd3ca574f6086a57906
Modified: 2025-10-01
CVE-2022-49891
In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd() test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd(). unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Modified: 2025-05-07
CVE-2022-49892
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]
Modified: 2025-11-10
CVE-2022-49893
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix cxl_region leak, cleanup targets at region delete When a region is deleted any targets that have been previously assigned to that region hold references to it. Trigger those references to drop by detaching all targets at unregister_region() time. Otherwise that region object will leak as userspace has lost the ability to detach targets once region sysfs is torn down.
Modified: 2025-10-01
CVE-2022-49894
In the Linux kernel, the following vulnerability has been resolved:
cxl/region: Fix region HPA ordering validation
Some regions may not have any address space allocated. Skip them when
validating HPA order otherwise a crash like the following may result:
devm_cxl_add_region: cxl_acpi cxl_acpi.0: decoder3.4: created region9
BUG: kernel NULL pointer dereference, address: 0000000000000000
[..]
RIP: 0010:store_targetN+0x655/0x1740 [cxl_core]
[..]
Call Trace:
Modified: 2025-10-01
CVE-2022-49895
In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fix decoder allocation crash When an intermediate port's decoders have been exhausted by existing regions, and creating a new region with the port in question in it's hierarchical path is attempted, cxl_port_attach_region() fails to find a port decoder (as would be expected), and drops into the failure / cleanup path. However, during cleanup of the region reference, a sanity check attempts to dereference the decoder, which in the above case didn't exist. This causes a NULL pointer dereference BUG. To fix this, refactor the decoder allocation and de-allocation into helper routines, and in this 'free' routine, check that the decoder, @cxld, is valid before attempting any operations on it.
Modified: 2025-10-01
CVE-2022-49896
In the Linux kernel, the following vulnerability has been resolved: cxl/pmem: Fix cxl_pmem_region and cxl_memdev leak When a cxl_nvdimm object goes through a ->remove() event (device physically removed, nvdimm-bridge disabled, or nvdimm device disabled), then any associated regions must also be disabled. As highlighted by the cxl-create-region.sh test [1], a single device may host multiple regions, but the driver was only tracking one region at a time. This leads to a situation where only the last enabled region per nvdimm device is cleaned up properly. Other regions are leaked, and this also causes cxl_memdev reference leaks. Fix the tracking by allowing cxl_nvdimm objects to track multiple region associations.
Modified: 2025-11-10
CVE-2022-49898
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix tree mod log mishandling of reallocated nodes We have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40 Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n); This occurs because we replay the nodes in order that they happened, and when we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot, starting at 0. 'n' here is the number of items in this block, which in this case was 1, but we had 2 REMOVE_WHILE_FREEING operations. The actual root cause of this was that we were replaying operations for a block that shouldn't have been replayed. Consider the following sequence of events 1. We have an already modified root, and we do a btrfs_get_tree_mod_seq(). 2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots. 3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node. 4. We modify a new root, and re-allocate the above node to the root node of this other root. The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8 >From here the bug is triggered by the following steps 1. Call btrfs_get_old_root() on the new_root. 2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0. 3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE. 4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e ---truncated---
Modified: 2025-10-01
CVE-2022-49899
In the Linux kernel, the following vulnerability has been resolved: fscrypt: stop using keyrings subsystem for fscrypt_master_key The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support.
Modified: 2025-11-10
CVE-2022-49900
In the Linux kernel, the following vulnerability has been resolved:
i2c: piix4: Fix adapter not be removed in piix4_remove()
In piix4_probe(), the piix4 adapter will be registered in:
piix4_probe()
piix4_add_adapters_sb800() / piix4_add_adapter()
i2c_add_adapter()
Based on the probed device type, piix4_add_adapters_sb800() or single
piix4_add_adapter() will be called.
For the former case, piix4_adapter_count is set as the number of adapters,
while for antoher case it is not set and kept default *zero*.
When piix4 is removed, piix4_remove() removes the adapters added in
piix4_probe(), basing on the piix4_adapter_count value.
Because the count is zero for the single adapter case, the adapter won't
be removed and makes the sources allocated for adapter leaked, such as
the i2c client and device.
These sources can still be accessed by i2c or bus and cause problems.
An easily reproduced case is that if a new adapter is registered, i2c
will get the leaked adapter and try to call smbus_algorithm, which was
already freed:
Triggered by: rmmod i2c_piix4 && modprobe max31730
BUG: unable to handle page fault for address: ffffffffc053d860
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 3752 Comm: modprobe Tainted: G
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core
RSP: 0018:ffff888107477710 EFLAGS: 00000246
...
Modified: 2025-10-01
CVE-2022-49901
In the Linux kernel, the following vulnerability has been resolved: blk-mq: Fix kmemleak in blk_mq_init_allocated_queue There is a kmemleak caused by modprobe null_blk.ko unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 That is because q->ma_ops is set to NULL before blk_release_queue is called. blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q); [1]: blk_mq_alloc_and_init_hctx failed at i != 0. [2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and will be cleaned up in blk_mq_release. [3]: q->nr_hw_queues is 0. [4]: Set q->mq_ops to NULL. [5]: queue_is_mq returns false due to [4]. And blk_mq_release will not be called. The hctxs in q->unused_hctx_list are leaked. To fix it, call blk_release_queue in exception path.
Modified: 2025-10-01
CVE-2022-49902
In the Linux kernel, the following vulnerability has been resolved: block: Fix possible memory leak for rq_wb on add_disk failure kmemleak reported memory leaks in device_add_disk(): kmemleak: 3 new suspected memory leaks unreferenced object 0xffff88800f420800 (size 512): comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s) hex dump (first 32 bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d3662699>] kmalloc_trace+0x26/0x60 [<00000000edc7aadc>] wbt_init+0x50/0x6f0 [<0000000069601d16>] wbt_enable_default+0x157/0x1c0 [<0000000028fc393f>] blk_register_queue+0x2a4/0x420 [<000000007345a042>] device_add_disk+0x6fd/0xe40 [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd] ... It is because the memory allocated in wbt_enable_default() is not released in device_add_disk() error path. Normally, these memory are freed in: del_gendisk() rq_qos_exit() rqos->ops->exit(rqos); wbt_exit() So rq_qos_exit() is called to free the rq_wb memory for wbt_init(). However in the error path of device_add_disk(), only blk_unregister_queue() is called and make rq_wb memory leaked. Add rq_qos_exit() to the error path to fix it.
Modified: 2025-11-11
CVE-2022-49903
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix WARNING in ip6_route_net_exit_late()
During the initialization of ip6_route_net_init_late(), if file
ipv6_route or rt6_stats fails to be created, the initialization is
successful by default. Therefore, the ipv6_route or rt6_stats file
doesn't be found during the remove in ip6_route_net_exit_late(). It
will cause WRNING.
The following is the stack information:
name 'rt6_stats'
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/080589287127838046077904f34d5054ea0f895c
- https://git.kernel.org/stable/c/0ed71af4d017d2bd2cbb8f7254f613a4914def26
- https://git.kernel.org/stable/c/381453770f731f0f43616a1cd4c759b7807a1517
- https://git.kernel.org/stable/c/5dbb47ee89762da433cd8458788d7640c85f1a07
- https://git.kernel.org/stable/c/768b3c745fe5789f2430bdab02f35a9ad1148d97
- https://git.kernel.org/stable/c/83fbf246ced54dadd7b9adc2a16efeff30ba944d
Modified: 2025-10-01
CVE-2022-49904
In the Linux kernel, the following vulnerability has been resolved:
net, neigh: Fix null-ptr-deref in neigh_table_clear()
When IPv6 module gets initialized but hits an error in the middle,
kenel panic with:
KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
CPU: 1 PID: 361 Comm: insmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
RSP: 0018:ffff888012677908 EFLAGS: 00000202
...
Call Trace:
- https://git.kernel.org/stable/c/0d38b4ca6679e72860ff8730e79bb99d0e9fa3b0
- https://git.kernel.org/stable/c/1c89642e7f2b7ecc9635610653f5c2f0276c0051
- https://git.kernel.org/stable/c/2b45d6d0c41cb9593868e476681efb1aae5078a1
- https://git.kernel.org/stable/c/a99a8ec4c62180c889482a2ff6465033e0743458
- https://git.kernel.org/stable/c/b49f6b2f21f543d4dc88fb7b1ec2adccb822f27c
- https://git.kernel.org/stable/c/b736592de2aa53aee2d48d6b129bc0c892007bbe
- https://git.kernel.org/stable/c/f8017317cb0b279b8ab98b0f3901a2e0ac880dad
Modified: 2025-11-11
CVE-2022-49905
In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible leaked pernet namespace in smc_init()
In smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called
without any error handling.
If it fails, registering of &smc_net_ops won't be reverted.
And if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted.
This leaves wild ops in subsystem linkedlist and when another module
tries to call register_pernet_operations() it triggers page fault:
BUG: unable to handle page fault for address: fffffbfff81b964c
RIP: 0010:register_pernet_operations+0x1b9/0x5f0
Call Trace:
Modified: 2025-10-01
CVE-2022-49906
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Free rwi on reset success Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed.
Modified: 2025-11-11
CVE-2022-49907
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/20ed01a7b9af6e6a3c33761eebbb710ea6dd49b7
- https://git.kernel.org/stable/c/40e4eb324c59e11fcb927aa46742d28aba6ecb8a
- https://git.kernel.org/stable/c/4954b5359eb141499492fadfab891e28905509e2
- https://git.kernel.org/stable/c/634f066d02bdb22a26da7deb0c7617ab1a65fc9d
- https://git.kernel.org/stable/c/6ce6f8f8f6316da6f92afe7490bc2f0b654d68e0
- https://git.kernel.org/stable/c/7006176a3c863e3e353ce1b8a349ef5bb1b9320e
- https://git.kernel.org/stable/c/985a88bf0b27193522bba7856b1763f428cef19d
- https://git.kernel.org/stable/c/a3fafc974be37319679f36dc4e7cca7db1e02973
Modified: 2025-10-01
CVE-2022-49908
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix memory leak in vhci_write
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810d81ac00 (size 240):
[...]
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
Modified: 2025-11-11
CVE-2022-49910
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
- https://git.kernel.org/stable/c/03af22e23b96fb7ef75fb7885407ef457e8b403d
- https://git.kernel.org/stable/c/3aff8aaca4e36dc8b17eaa011684881a80238966
- https://git.kernel.org/stable/c/4cd094fd5d872862ca278e15b9b51b07e915ef3f
- https://git.kernel.org/stable/c/6c7407bfbeafc80a04e6eaedcf34d378532a04f2
- https://git.kernel.org/stable/c/8278a87bb1eeea94350d675ef961ee5a03341fde
- https://git.kernel.org/stable/c/9a04161244603f502c6e453913e51edd59cb70c1
- https://git.kernel.org/stable/c/cb1c012099ef5904cd468bdb8d6fcdfdd9bcb569
- https://git.kernel.org/stable/c/dc30e05bb18852303084430c03ca76e69257d9ea
Modified: 2025-11-11
CVE-2022-49911
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: enforce documented limit to prevent allocating huge memory
Daniel Xu reported that the hash:net,iface type of the ipset subsystem does
not limit adding the same network with different interfaces to a set, which
can lead to huge memory usage or allocation failure.
The quick reproducer is
$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0
$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done
The backtrace when vmalloc fails:
[Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages
<...>
[Tue Oct 25 00:13:08 2022] Call Trace:
[Tue Oct 25 00:13:08 2022]
Modified: 2025-11-12
CVE-2022-49912
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ulist leaks in error paths of qgroup self tests In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests, if we fail to add the tree ref, remove the extent item or remove the extent ref, we are returning from the test function without freeing the "old_roots" ulist that was allocated by the previous calls to btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
- https://git.kernel.org/stable/c/0a0dead4ad1a2e2a9bdf133ef45111d7c8daef84
- https://git.kernel.org/stable/c/203204798831c35d855ecc6417d98267d2d2184b
- https://git.kernel.org/stable/c/3f58283d83a588ff5da62fc150de19e798ed2ec2
- https://git.kernel.org/stable/c/5d1a47ebf84540e40b5b43fc21aef0d6c0f627d9
- https://git.kernel.org/stable/c/d37de92b38932d40e4a251e876cc388f9aee5f42
- https://git.kernel.org/stable/c/d81370396025cf63a7a1b5f8bb25a3479203b2ca
- https://git.kernel.org/stable/c/da7003434bcab0ae9aba3f2c003e734cae093326
- https://git.kernel.org/stable/c/f46ea5fa3320dca4fe0c0926b49a5f14cb85de62
Modified: 2025-11-12
CVE-2022-49913
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at find_parent_nodes() During backref walking, at find_parent_nodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolve_indirect_refs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to the refs ulist passed as argument to find_parent_nodes(). Since they were not yet added to the refs ulist and prelim_release() does not free the lists, on error the caller can only free the lists attached to the refs that were added to the refs ulist, all the remaining refs get their inode lists never freed, therefore leaking their memory. Fix this by having prelim_release() always free any attached inode list to each ref found in the rbtree, and have find_parent_nodes() set the ref's inode list to NULL once it transfers ownership of the inode list to a ref added to the refs ulist passed to find_parent_nodes().
- https://git.kernel.org/stable/c/222a3d533027b9492d5b7f5ecdc01a90f57bb5a9
- https://git.kernel.org/stable/c/61e06128113711df0534c404fb6bb528eb7d2332
- https://git.kernel.org/stable/c/6a6731a0df8c47ecc703bd7bb73459df767051e0
- https://git.kernel.org/stable/c/83ea8c5b54d452a5769e605e3c5c687e8ca06d89
- https://git.kernel.org/stable/c/92876eec382a0f19f33d09d2c939e9ca49038ae5
Modified: 2025-11-12
CVE-2022-49914
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the unodes. Fix this by calling free_leaf_list() instead of ulist_free() when we exit from resolve_indirect_refs(). The static function free_leaf_list() is moved up for this to be possible and it's slightly simplified by removing unnecessary code.
- https://git.kernel.org/stable/c/2c0329406bb28109c07c6e23e5e3e0fa618a95d7
- https://git.kernel.org/stable/c/396515db923ad5cbeb179d6b88927870b4cbebb7
- https://git.kernel.org/stable/c/5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1
- https://git.kernel.org/stable/c/6ba3479f9e96b9ad460c7e77abc26dd16e5dec4f
- https://git.kernel.org/stable/c/a52e24c7fcc3c5ce3588a14e3663c00868d36623
- https://git.kernel.org/stable/c/b1dc9019bb5f89abae85645de1a2dd4830c1f8e9
- https://git.kernel.org/stable/c/cded2c89774b99b67c98147ae103ea878c92a206
Modified: 2025-10-01
CVE-2022-49915
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release().
- https://git.kernel.org/stable/c/029d5b7688a2f3a86f2a3be5a6ba9cc968c80e41
- https://git.kernel.org/stable/c/080aabfb29b2ee9cbb8894a1d039651943d3773e
- https://git.kernel.org/stable/c/0d4e91efcaee081e919b3c50e875ecbb84290e41
- https://git.kernel.org/stable/c/2ff6b669523d3b3d253a044fa9636a67d0694995
- https://git.kernel.org/stable/c/a636fc5a7cabd05699b5692ad838c2c7a3abec7b
- https://git.kernel.org/stable/c/d1d1aede313eb2b9a84afd60ff6cfb7c33631e0e
- https://git.kernel.org/stable/c/e77d213843e67b4373285712699b692f9c743f61
- https://git.kernel.org/stable/c/e7d1d4d9ac0dfa40be4c2c8abd0731659869b297
Modified: 2025-10-01
CVE-2022-49916
In the Linux kernel, the following vulnerability has been resolved:
rose: Fix NULL pointer dereference in rose_send_frame()
The syzkaller reported an issue:
KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: rcu_gp srcu_invoke_callbacks
RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
Call Trace:
- https://git.kernel.org/stable/c/01b9c68c121847d05a4ccef68244dadf82bfa331
- https://git.kernel.org/stable/c/3e2129c67daca21043a26575108f6286c85e71f6
- https://git.kernel.org/stable/c/5b46adfbee1e429f33b10a88d6c00fa88f3d6c77
- https://git.kernel.org/stable/c/a601e5eded33bb88b8a42743db8fef3ad41dd97e
- https://git.kernel.org/stable/c/b13be5e852b03f376058027e462fad4230240891
- https://git.kernel.org/stable/c/bbc03d74e641e824754443b908454ca9e203773e
- https://git.kernel.org/stable/c/e97c089d7a49f67027395ddf70bf327eeac2611e
- https://git.kernel.org/stable/c/f06186e5271b980bac03f5c97276ed0146ddc9b0
Modified: 2025-11-12
CVE-2022-49917
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in ip_vs_app_net_cleanup()
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/06d7596d18725f1a93cf817662d36050e5afb989
- https://git.kernel.org/stable/c/2c8d81bdb2684d53d6cedad7410ba4cf9090e343
- https://git.kernel.org/stable/c/5663ed63adb9619c98ab7479aa4606fa9b7a548c
- https://git.kernel.org/stable/c/8457a00c981fe1a799ce34123908856b0f5973b8
- https://git.kernel.org/stable/c/97f872b00937f2689bff2dab4ad9ed259482840f
- https://git.kernel.org/stable/c/adc76740ccd52e4a1d910767cd1223e134a7078b
Modified: 2025-11-12
CVE-2022-49918
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in __ip_vs_cleanup_batch()
During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
or ip_vs_conn_sync fails to be created, the initialization is successful
by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
be found during the remove.
The following is the stack information:
name 'ip_vs_conn_sync'
WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/3d00c6a0da8ddcf75213e004765e4a42acc71d5d
- https://git.kernel.org/stable/c/5ee2d6b726b0ce339e36569e5849692f4cf4595e
- https://git.kernel.org/stable/c/7effc4ce3d1434ce6ff286866585a6e905fdbfc1
- https://git.kernel.org/stable/c/931f56d59c854263b32075bfac56fdb3b1598d1b
- https://git.kernel.org/stable/c/e724220b826e008764309d2a1f55a9434a4e1530
- https://git.kernel.org/stable/c/f08ee2aa24c076f81d84e26e213d8c6f4efd9f50
Modified: 2025-10-01
CVE-2022-49919
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flow rule object from commit path No need to postpone this to the commit release path, since no packets are walking over this object, this is accessed from control plane only. This helped uncovered UAF triggered by races with the netlink notifier.
- https://git.kernel.org/stable/c/26b5934ff4194e13196bedcba373cd4915071d0e
- https://git.kernel.org/stable/c/4ab6f96444e936f5e4a936d5c0bc948144bcded3
- https://git.kernel.org/stable/c/6044791b7be707fd0e709f26e961a446424e5051
- https://git.kernel.org/stable/c/74fd5839467054cd9c4d050614d3ee8788386171
- https://git.kernel.org/stable/c/b2d7a92aff0fbd93c29d2aa6451fb99f050e2c4e
Modified: 2025-10-01
CVE-2022-49920
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: netlink notifier might race to release objects commit release path is invoked via call_rcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path. Call rcu_barrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty.
Modified: 2025-10-01
CVE-2022-49921
In the Linux kernel, the following vulnerability has been resolved: net: sched: Fix use after free in red_enqueue() We can't use "skb" again after passing it to qdisc_enqueue(). This is basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb len before calling child enqueue").
- https://git.kernel.org/stable/c/170e5317042c302777ed6d59fdb84af9b0219d4e
- https://git.kernel.org/stable/c/52e0429471976785c155bfbf51d80990c6cd46e2
- https://git.kernel.org/stable/c/5960b9081baca85cc7dcb14aec1de85999ea9d36
- https://git.kernel.org/stable/c/795afe0b9bb6c915f0299a8e309936519be01619
- https://git.kernel.org/stable/c/8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9
- https://git.kernel.org/stable/c/a238cdcf2bdc72207c74375fc8be13ee549ca9db
- https://git.kernel.org/stable/c/e877f8fa49fbccc63cb2df2e9179bddc695b825a
- https://git.kernel.org/stable/c/fc4b50adb400ee5ec527a04073174e8e73a139fa
Modified: 2025-10-01
CVE-2022-49922
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds.
- https://git.kernel.org/stable/c/52438e734c1566f5e2bcd9a065d2d65e306c0555
- https://git.kernel.org/stable/c/5dfdac5e3f8db5f4445228c44f64091045644a3b
- https://git.kernel.org/stable/c/825656ae61e73ddc05f585e6258d284c87064b10
- https://git.kernel.org/stable/c/92a1df9c6da20c02cf9872f8b025a66ddb307aeb
- https://git.kernel.org/stable/c/93d904a734a74c54d945a9884b4962977f1176cd
- https://git.kernel.org/stable/c/c8e7d4a1166f063703955f1b2e765a6db5bf1771
- https://git.kernel.org/stable/c/dd0ee55ead91fbb16889dbe7ff0b0f7c9e4e849d
- https://git.kernel.org/stable/c/f30060efcf18883748a0541aa41acef183cd9c0e
Modified: 2025-10-01
CVE-2022-49923
In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds.
Modified: 2025-10-01
CVE-2022-49924
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished.
Modified: 2025-10-01
CVE-2022-49925
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
- https://git.kernel.org/stable/c/07c0d131cc0fe1f3981a42958fc52d573d303d89
- https://git.kernel.org/stable/c/6b3d5dcb12347f3518308c2c9d2cf72453a3e1e5
- https://git.kernel.org/stable/c/ab817f75e5e0fa58d9be0825da6a7b7d8a1fa1d9
- https://git.kernel.org/stable/c/af8fb5a0600e9ae29950e9422a032c3c22649ee5
- https://git.kernel.org/stable/c/d360e875c011a005628525bf290322058927e7dc
Modified: 2025-10-01
CVE-2022-49926
In the Linux kernel, the following vulnerability has been resolved: net: dsa: Fix possible memory leaks in dsa_loop_init() kmemleak reported memory leaks in dsa_loop_init(): kmemleak: 12 new suspected memory leaks unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ... There are two reasons for memleak in dsa_loop_init(). First, fixed_phy_register() create and register phy_device: fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove() But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked. Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs. Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.
- https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e
- https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254
- https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50
- https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3
- https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7
- https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f
- https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c
Modified: 2025-10-01
CVE-2022-49927
In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d
- https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67
- https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593
- https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c
- https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d
- https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127
- https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb
- https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401
Modified: 2025-10-01
CVE-2022-49928
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed
There is a null-ptr-deref when xps sysfs alloc failed:
BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0
Read of size 8 at addr 0000000000000030 by task gssproxy/457
CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9
Call Trace:
Modified: 2025-11-12
CVE-2022-49929
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix mr leak in RESPST_ERR_RNR rxe_recheck_mr() will increase mr's ref_cnt, so we should call rxe_put(mr) to drop mr's ref_cnt in RESPST_ERR_RNR to avoid below warning: WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe] ... Call Trace: rxe_dereg_mr+0x4c/0x60 [rdma_rxe] ib_dereg_mr_user+0xa8/0x200 [ib_core] ib_mr_pool_destroy+0x77/0xb0 [ib_core] nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma] nvme_rdma_free_queue+0x40/0x50 [nvme_rdma] nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma] nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma] process_one_work+0x582/0xa40 ? pwq_dec_nr_in_flight+0x100/0x100 ? rwlock_bug.part.0+0x60/0x60 worker_thread+0x2a9/0x700 ? process_one_work+0xa40/0xa40 kthread+0x168/0x1a0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Modified: 2025-10-01
CVE-2022-49930
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix NULL pointer problem in free_mr_init() Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL pointer. It should be init mutex_init() first before use the lock. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: __mutex_lock.constprop.0+0xd0/0x5c0 __mutex_lock_slowpath+0x1c/0x2c mutex_lock+0x44/0x50 free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2] hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2] hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2] ib_dereg_mr_user+0x54/0x124 uverbs_free_mr+0x24/0x30 destroy_hw_idr_uobject+0x38/0x74 uverbs_destroy_uobject+0x48/0x1c4 uobj_destroy+0x74/0xcc ib_uverbs_cmd_verbs+0x368/0xbb0 ib_uverbs_ioctl+0xec/0x1a4 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x190 do_el0_svc+0x30/0x90 el0_svc+0x2c/0xb4 el0t_64_sync_handler+0x1a4/0x1b0 el0t_64_sync+0x19c/0x1a0
Modified: 2025-10-01
CVE-2022-49931
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list.
- https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55
- https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e
- https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0
- https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c
- https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926
Modified: 2025-11-24
CVE-2022-50239
In the Linux kernel, the following vulnerability has been resolved: cpufreq: qcom: fix writes in read-only memory region This commit fixes a kernel oops because of a write in some read-only memory: [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271] __memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190 [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c ..snip.. The following line defines a pointer that point to a char buffer stored in read-only memory: char *pvs_name = "speedXX-pvsXX-vXX"; This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the XX values get overridden by the qcom_cpufreq_krait_name_version function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops: snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the stack by using the following syntax: char pvs_name_buffer[] = "speedXX-pvsXX-vXX"; Because the `pvs_name` needs to be able to be assigned to NULL, the template buffer is stored in the pvs_name_buffer and not under the pvs_name variable.
Modified: 2025-11-25
CVE-2022-50254
In the Linux kernel, the following vulnerability has been resolved: media: ov8865: Fix an error handling path in ov8865_probe() The commit in Fixes also introduced some new error handling which should goto the existing error handling path. Otherwise some resources leak.
Modified: 2025-12-03
CVE-2022-50265
In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_wait kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. syzbot reported: BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: reserve_rx_kcm net/kcm/kcmsock.c:283 [inline] kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x01 -> 0x00 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
- https://git.kernel.org/stable/c/0c745b5141a45a076f1cb9772a399f7ebcb0948a
- https://git.kernel.org/stable/c/2733fb2ad5bfbe6538f2f93a21f2504e3dba9d6a
- https://git.kernel.org/stable/c/62086d1c4602e4f2ec07b975165afc2ed0ff1be9
- https://git.kernel.org/stable/c/663682cd3192dd4f3547b7890a4391c72441001d
- https://git.kernel.org/stable/c/9ae47f11493509cde707af8ecc7eee04c8b8e635
- https://git.kernel.org/stable/c/dbc3a0b917c4f75292b1c0819c188e40fd3c8924
- https://git.kernel.org/stable/c/e2a28807b1ceaa309164b92c38d73d12feea33df
- https://git.kernel.org/stable/c/f1f7122bb2ef056afc6f91ce4c35ab6df1207c8d
Modified: 2025-12-04
CVE-2022-50283
In the Linux kernel, the following vulnerability has been resolved: mtd: core: add missing of_node_get() in dynamic partitions code This fixes unbalanced of_node_put(): [ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand [ 1.085116] Creating 6 MTD partitions on "gpmi-nand": [ 1.090181] 0x000000000000-0x000008000000 : "nandboot" [ 1.096952] 0x000008000000-0x000009000000 : "nandfit" [ 1.103547] 0x000009000000-0x00000b000000 : "nandkernel" [ 1.110317] 0x00000b000000-0x00000c000000 : "nanddtb" [ 1.115525] ------------[ cut here ]------------ [ 1.120141] refcount_t: addition on 0; use-after-free. [ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xdc/0x148 [ 1.133528] Modules linked in: [ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7 [ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT) [ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158965] pc : refcount_warn_saturate+0xdc/0x148 [ 1.163760] lr : refcount_warn_saturate+0xdc/0x148 [ 1.168556] sp : ffff800009ddb080 [ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002 [ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05 [ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000 [ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff [ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004 [ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003 [ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00 [ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b [ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000 [ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a [ 1.243365] Call trace: [ 1.245806] refcount_warn_saturate+0xdc/0x148 [ 1.250253] kobject_get+0x98/0x9c [ 1.253658] of_node_get+0x20/0x34 [ 1.257072] of_fwnode_get+0x3c/0x54 [ 1.260652] fwnode_get_nth_parent+0xd8/0xf4 [ 1.264926] fwnode_full_name_string+0x3c/0xb4 [ 1.269373] device_node_string+0x498/0x5b4 [ 1.273561] pointer+0x41c/0x5d0 [ 1.276793] vsnprintf+0x4d8/0x694 [ 1.280198] vprintk_store+0x164/0x528 [ 1.283951] vprintk_emit+0x98/0x164 [ 1.287530] vprintk_default+0x44/0x6c [ 1.291284] vprintk+0xf0/0x134 [ 1.294428] _printk+0x54/0x7c [ 1.297486] of_node_release+0xe8/0x128 [ 1.301326] kobject_put+0x98/0xfc [ 1.304732] of_node_put+0x1c/0x28 [ 1.308137] add_mtd_device+0x484/0x6d4 [ 1.311977] add_mtd_partitions+0xf0/0x1d0 [ 1.316078] parse_mtd_partitions+0x45c/0x518 [ 1.320439] mtd_device_parse_register+0xb0/0x274 [ 1.325147] gpmi_nand_probe+0x51c/0x650 [ 1.329074] platform_probe+0xa8/0xd0 [ 1.332740] really_probe+0x130/0x334 [ 1.336406] __driver_probe_device+0xb4/0xe0 [ 1.340681] driver_probe_device+0x3c/0x1f8 [ 1.344869] __driver_attach+0xdc/0x1a4 [ 1.348708] bus_for_each_dev+0x80/0xcc [ 1.352548] driver_attach+0x24/0x30 [ 1.356127] bus_add_driver+0x108/0x1f4 [ 1.359967] driver_register+0x78/0x114 [ 1.363807] __platform_driver_register+0x24/0x30 [ 1.368515] gpmi_nand_driver_init+0x1c/0x28 [ 1.372798] do_one_initcall+0xbc/0x238 [ 1.376638] do_initcall_level+0x94/0xb4 [ 1.380565] do_initcalls+0x54/0x94 [ 1.384058] do_basic_setup+0x1c/0x28 [ 1.387724] kernel_init_freeable+0x110/0x188 [ 1.392084] kernel_init+0x20/0x1a0 [ 1.395578] ret_from_fork+0x10/0x20 [ 1.399157] ---[ end trace 0000000000000000 ]--- [ 1.403782] ------------[ cut here ]------------
Modified: 2025-12-04
CVE-2022-50285
In the Linux kernel, the following vulnerability has been resolved: mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages The h->*_huge_pages counters are protected by the hugetlb_lock, but alloc_huge_page has a corner case where it can decrement the counter outside of the lock. This could lead to a corrupted value of h->resv_huge_pages, which we have observed on our systems. Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a potential race.
- https://git.kernel.org/stable/c/112a005d1ded04a4b41b6d01833cc0bda90625cc
- https://git.kernel.org/stable/c/11993652d0b49e27272db0a37aa828d8a3a4b92b
- https://git.kernel.org/stable/c/12df140f0bdfae5dcfc81800970dd7f6f632e00c
- https://git.kernel.org/stable/c/2b35432d324898ec41beb27031d2a1a864a4d40e
- https://git.kernel.org/stable/c/3e50a07b6a5fcd39df1534d3fdaca4292a65efe6
- https://git.kernel.org/stable/c/568e3812b1778b4c0c229649b59977d88f400ece
- https://git.kernel.org/stable/c/629c986e19fe9481227c7cdfd9a105bbc104d245
- https://git.kernel.org/stable/c/c828fab903725279aa9dc6ae3d44bb7e4778f92c
Modified: 2025-12-04
CVE-2022-50291
In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_psock kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. We do the same for kcm->rx_wait in the following patch. syzbot reported: BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1: unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313 kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffff88812971ce00 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
- https://git.kernel.org/stable/c/12a0eb340c9a22e0f8c00d2c0c1a60695ead926a
- https://git.kernel.org/stable/c/13dba69e18d04c8eec7596369f2a0596b0260275
- https://git.kernel.org/stable/c/15e4dabda11b0fa31d510a915d1a580f47dfc92e
- https://git.kernel.org/stable/c/1b8a5692ab25db4ef1c2cc8e5d21f7a65dc3d079
- https://git.kernel.org/stable/c/342d918cf9a45df9cf11bbe7162b851adefd178f
- https://git.kernel.org/stable/c/bf46af730e58d340f6f740bc69a07c5f6b85c655
- https://git.kernel.org/stable/c/c325f92d8d9b223d5842609ca067e898e9d34566
- https://git.kernel.org/stable/c/e94395e916b48a5b912a0a04570981b5b091acb0
Modified: 2025-12-04
CVE-2022-50292
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix bridge lifetime Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP bridges, previously allocated bridges will leak on probe deferral. Fix this by amending the DP parser interface and tying the lifetime of the bridge device to the DRM device rather than DP platform device. Patchwork: https://patchwork.freedesktop.org/patch/502667/
Modified: 2025-12-04
CVE-2022-50295
In the Linux kernel, the following vulnerability has been resolved:
io_uring/msg_ring: Fix NULL pointer dereference in io_msg_send_fd()
Syzkaller produced the below call trace:
BUG: KASAN: null-ptr-deref in io_msg_ring+0x3cb/0x9f0
Write of size 8 at addr 0000000000000070 by task repro/16399
CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
Call Trace:
Modified: 2025-12-04
CVE-2022-50306
In the Linux kernel, the following vulnerability has been resolved: ext4: fix potential out of bound read in ext4_fc_replay_scan() For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read when mounting corrupt file system image. ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this three tags will read data during scan, tag length couldn't less than data length which will read.
Modified: 2025-12-04
CVE-2022-50307
In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix out-of-bounds access on cio_ignore free The channel-subsystem-driver scans for newly available devices whenever device-IDs are removed from the cio_ignore list using a command such as: echo free >/proc/cio_ignore Since an I/O device scan might interfer with running I/Os, commit 172da89ed0ea ("s390/cio: avoid excessive path-verification requests") introduced an optimization to exclude online devices from the scan. The newly added check for online devices incorrectly assumes that an I/O-subchannel's drvdata points to a struct io_subchannel_private. For devices that are bound to a non-default I/O subchannel driver, such as the vfio_ccw driver, this results in an out-of-bounds read access during each scan. Fix this by changing the scan logic to rely on a driver-independent online indication. For this we can use struct subchannel->config.ena, which is the driver's requested subchannel-enabled state. Since I/Os can only be started on enabled subchannels, this matches the intent of the original optimization of not scanning devices where I/O might be running.
Modified: 2025-12-04
CVE-2022-50310
In the Linux kernel, the following vulnerability has been resolved:
ip6mr: fix UAF issue in ip6mr_sk_done() when addrconf_init_net() failed
If the initialization fails in calling addrconf_init_net(), devconf_all is
the pointer that has been released. Then ip6mr_sk_done() is called to
release the net, accessing devconf->mc_forwarding directly causes invalid
pointer access.
The process is as follows:
setup_net()
ops_init()
addrconf_init_net()
all = kmemdup(...) ---> alloc "all"
...
net->ipv6.devconf_all = all;
__addrconf_sysctl_register() ---> failed
...
kfree(all); ---> ipv6.devconf_all invalid
...
ops_exit_list()
...
ip6mr_sk_done()
devconf = net->ipv6.devconf_all;
//devconf is invalid pointer
if (!devconf || !atomic_read(&devconf->mc_forwarding))
The following is the Call Trace information:
BUG: KASAN: use-after-free in ip6mr_sk_done+0x112/0x3a0
Read of size 4 at addr ffff888075508e88 by task ip/14554
Call Trace:
Modified: 2025-12-04
CVE-2022-50315
In the Linux kernel, the following vulnerability has been resolved:
ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS
UBSAN complains about array-index-out-of-bounds:
[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41
[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'
[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu
[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010
[ 1.980718] kernel: Call Trace:
[ 1.980721] kernel:
- https://git.kernel.org/stable/c/1e41e693f458eef2d5728207dbd327cd3b16580a
- https://git.kernel.org/stable/c/303d0f761431d848dd8d7ff9fd9b8c101879cabe
- https://git.kernel.org/stable/c/383b7c50f5445ff8dbbf03080905648d6980c39d
- https://git.kernel.org/stable/c/67a00c299c5c143817c948fbc7de1a2fa1af38fb
- https://git.kernel.org/stable/c/8fbe13de1cc7cef2564be3cbf60400b33eee023b
- https://git.kernel.org/stable/c/d6314d5f68764550c84d732ce901ddd3ac6b415f
- https://git.kernel.org/stable/c/da2ea4a961d9f89ed248734e7032350c260dc3a3
- https://git.kernel.org/stable/c/f70bd4339cb68bc7e206af4c922bc0d249244403
Modified: 2025-12-04
CVE-2022-50323
In the Linux kernel, the following vulnerability has been resolved: net: do not sense pfmemalloc status in skb_append_pagefrags() skb_append_pagefrags() is used by af_unix and udp sendpage() implementation so far. In commit 326140063946 ("tcp: TX zerocopy should not sense pfmemalloc status") we explained why we should not sense pfmemalloc status for pages owned by user space. We should also use skb_fill_page_desc_noacc() in skb_append_pagefrags() to avoid following KCSAN report: BUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:323 [inline] lru_add_fn+0x327/0x410 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 lru_add_drain_cpu+0x73/0x250 mm/swap.c:669 lru_add_drain+0x21/0x60 mm/swap.c:773 free_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311 tlb_batch_pages_flush mm/mmu_gather.c:59 [inline] tlb_flush_mmu_free mm/mmu_gather.c:256 [inline] tlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263 tlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363 exit_mmap+0x190/0x4d0 mm/mmap.c:3098 __mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copy_process+0x19fc/0x2100 kernel/fork.c:2518 kernel_clone+0x166/0x550 kernel/fork.c:2671 __do_sys_clone kernel/fork.c:2812 [inline] __se_sys_clone kernel/fork.c:2796 [inline] __x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1817 [inline] __skb_fill_page_desc include/linux/skbuff.h:2432 [inline] skb_fill_page_desc include/linux/skbuff.h:2453 [inline] skb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974 unix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xffffea00058fc188 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
Modified: 2025-12-03
CVE-2022-50331
In the Linux kernel, the following vulnerability has been resolved: wwan_hwsim: fix possible memory leak in wwan_hwsim_dev_new() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff88810152ad20 (size 8): comm "modprobe", pid 252, jiffies 4294849206 (age 22.713s) hex dump (first 8 bytes): 68 77 73 69 6d 30 00 ff hwsim0.. backtrace: [<000000009c3504ed>] __kmalloc_node_track_caller+0x44/0x1b0 [<00000000c0228a5e>] kvasprintf+0xb5/0x140 [<00000000cff8c21f>] kvasprintf_const+0x55/0x180 [<0000000055a1e073>] kobject_set_name_vargs+0x56/0x150 [<000000000a80b139>] dev_set_name+0xab/0xe0
Modified: 2025-12-04
CVE-2022-50332
In the Linux kernel, the following vulnerability has been resolved:
video/aperture: Call sysfb_disable() before removing PCI devices
Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
before removing PCI devices. Without, simpledrm can still bind to
simple-framebuffer devices after the hardware driver has taken over
the hardware. Both drivers interfere with each other and results are
undefined.
Reported modesetting errors [1] are shown below.
---- snap ----
rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 13-.... } 7 jiffies s: 165 root: 0x2000/.
rcu: blocking rcu_node structures (internal RCU debug):
Task dump for CPU 13:
task:X state:R running task stack: 0 pid: 4242 ppid: 4228 flags:0x00000008
Call Trace:
Modified: 2026-01-14
CVE-2022-50351
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix xid leak in cifs_create() If the cifs already shutdown, we should free the xid before return, otherwise, the xid will be leaked.
Modified: 2026-01-14
CVE-2022-50352
In the Linux kernel, the following vulnerability has been resolved: net: hns: fix possible memory leak in hnae_ae_register() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
- https://git.kernel.org/stable/c/02dc0db19d944b4a90941db505ecf1aaec714be4
- https://git.kernel.org/stable/c/2974f3b330ef25f5d34a4948d04290c2cd7802cf
- https://git.kernel.org/stable/c/3b78453cca046d3b03853f0d077ad3ad130db886
- https://git.kernel.org/stable/c/7ae1345f6ad715acbcdc9e1ac28153684fd498bb
- https://git.kernel.org/stable/c/91f8f5342bee726ed5692583d58f69e7cc9ae60e
- https://git.kernel.org/stable/c/a3c148955c22fe1d94d7a2096005679c1f22eddf
- https://git.kernel.org/stable/c/dfc0337c6dceb6449403b33ecb141f4a1458a1e9
- https://git.kernel.org/stable/c/ff2f5ec5d009844ec28f171123f9e58750cef4bf
Modified: 2026-01-14
CVE-2022-50356
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sfb: fix null pointer access issue when sfb_init() fails
When the default qdisc is sfb, if the qdisc of dev_queue fails to be
inited during mqprio_init(), sfb_reset() is invoked to clear resources.
In this case, the q->qdisc is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
sfb_init()
tcf_block_get() --->failed, q->qdisc is NULL
...
qdisc_put()
...
sfb_reset()
qdisc_reset(q->qdisc) --->q->qdisc is NULL
ops = qdisc->ops
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:qdisc_reset+0x2b/0x6f0
Call Trace:
Modified: 2026-01-14
CVE-2022-50360
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix aux-bus EP lifetime Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred. This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made. For the DP aux-bus, an attempt to populate the bus a second time will simply fail ("DP AUX EP device already populated"). Fix this by tying the lifetime of the EP device to the DRM device rather than DP controller platform device. Patchwork: https://patchwork.freedesktop.org/patch/502672/
Modified: 2026-01-14
CVE-2022-50363
In the Linux kernel, the following vulnerability has been resolved:
skmsg: pass gfp argument to alloc_sk_msg()
syzbot found that alloc_sk_msg() could be called from a
non sleepable context. sk_psock_verdict_recv() uses
rcu_read_lock() protection.
We need the callers to pass a gfp_t argument to avoid issues.
syzbot report was:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3613, name: syz-executor414
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
INFO: lockdep is turned off.
CPU: 0 PID: 3613 Comm: syz-executor414 Not tainted 6.0.0-syzkaller-09589-g55be6084c8e0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
Modified: 2026-01-14
CVE-2022-50368
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502668/
- https://git.kernel.org/stable/c/21c4679af01f1027cb559330c2e7d410089b2b36
- https://git.kernel.org/stable/c/2e786eb2f9cebb07e317226b60054df510b60c65
- https://git.kernel.org/stable/c/4e5587cddb334f7a5bb1c49ea8bbfc966fafe1b8
- https://git.kernel.org/stable/c/9f035d1fb30648fe70ee01627eb131c56d699b35
- https://git.kernel.org/stable/c/e83b354890a3c1d5256162f87a6cc38c47ae7f20
- https://git.kernel.org/stable/c/f649ed0e1b7a1545f8e27267d3c468b3cb222ece
Modified: 2026-01-14
CVE-2022-50372
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix memory leak when build ntlmssp negotiate blob failed There is a memory leak when mount cifs: unreferenced object 0xffff888166059600 (size 448): comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s) hex dump (first 32 bytes): fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000060609a61>] mempool_alloc+0xe1/0x260 [<00000000adfa6c63>] cifs_small_buf_get+0x24/0x60 [<00000000ebb404c7>] __smb2_plain_req_init+0x32/0x460 [<00000000bcf875b4>] SMB2_sess_alloc_buffer+0xa4/0x3f0 [<00000000753a2987>] SMB2_sess_auth_rawntlmssp_negotiate+0xf5/0x480 [<00000000f0c1f4f9>] SMB2_sess_setup+0x253/0x410 [<00000000a8b83303>] cifs_setup_session+0x18f/0x4c0 [<00000000854bd16d>] cifs_get_smb_ses+0xae7/0x13c0 [<000000006cbc43d9>] mount_get_conns+0x7a/0x730 [<000000005922d816>] cifs_mount+0x103/0xd10 [<00000000e33def3b>] cifs_smb3_do_mount+0x1dd/0xc90 [<0000000078034979>] smb3_get_tree+0x1d5/0x300 [<000000004371f980>] vfs_get_tree+0x41/0xf0 [<00000000b670d8a7>] path_mount+0x9b3/0xdd0 [<000000005e839a7d>] __x64_sys_mount+0x190/0x1d0 [<000000009404c3b9>] do_syscall_64+0x35/0x80 When build ntlmssp negotiate blob failed, the session setup request should be freed.
Modified: 2026-01-14
CVE-2022-50380
In the Linux kernel, the following vulnerability has been resolved: mm: /proc/pid/smaps_rollup: fix no vma's null-deref Commit 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value seq_file") introduced a null-deref if there are no vma's in the task in show_smaps_rollup.
- https://git.kernel.org/stable/c/33fc9e26b7cb39f0d4219c875a2451802249c225
- https://git.kernel.org/stable/c/6bb8769326c46db3058780c0640dcc49d8187b24
- https://git.kernel.org/stable/c/97898139ca9b81ba9322a585e07490983c53b55a
- https://git.kernel.org/stable/c/a50ed2d28727ff605d95fb9a53be8ff94e8eaaf4
- https://git.kernel.org/stable/c/c4c84f06285e48f80e9843d0775ad92714ffc35a
- https://git.kernel.org/stable/c/dbe863bce7679c7f5ec0e993d834fe16c5e687b5
Modified: 2026-01-14
CVE-2022-50387
In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix the issue of CMDQ memory leaks When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is not released correctly. Fix it.
Modified: 2026-01-14
CVE-2022-50398
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: add atomic_check to bridge ops DRM commit_tails() will disable downstream crtc/encoder/bridge if both disable crtc is required and crtc->active is set before pushing a new frame downstream. There is a rare case that user space display manager issue an extra screen update immediately followed by close DRM device while down stream display interface is disabled. This extra screen update will timeout due to the downstream interface is disabled but will cause crtc->active be set. Hence the followed commit_tails() called by drm_release() will pass the disable downstream crtc/encoder/bridge conditions checking even downstream interface is disabled. This cause the crash to happen at dp_bridge_disable() due to it trying to access the main link register to push the idle pattern out while main link clocks is disabled. This patch adds atomic_check to prevent the extra frame will not be pushed down if display interface is down so that crtc->active will not be set neither. This will fail the conditions checking of disabling down stream crtc/encoder/bridge which prevent drm_release() from calling dp_bridge_disable() so that crash at dp_bridge_disable() prevented. There is no protection in the DRM framework to check if the display pipeline has been already disabled before trying again. The only check is the crtc_state->active but this is controlled by usermode using UAPI. Hence if the usermode sets this and then crashes, the driver needs to protect against double disable. SError Interrupt on CPU7, code 0x00000000be000411 -- SError CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __cmpxchg_case_acq_32+0x14/0x2c lr : do_raw_spin_lock+0xa4/0xdc sp : ffffffc01092b6a0 x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038 x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000 x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008 x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000 x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0 x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4 x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001 x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0 x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) Call trace: dump_backtrace.part.0+0xbc/0xe4 show_stack+0x24/0x70 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 panic+0x14c/0x32c nmi_panic+0x58/0x7c arm64_serror_panic+0x78/0x84 do_serror+0x40/0x64 el1h_64_error_handler+0x30/0x48 el1h_64_error+0x68/0x6c __cmpxchg_case_acq_32+0x14/0x2c _raw_spin_lock_irqsave+0x38/0x4c lock_timer_base+0x40/0x78 __mod_timer+0xf4/0x25c schedule_timeout+0xd4/0xfc __wait_for_common+0xac/0x140 wait_for_completion_timeout+0x2c/0x54 dp_ctrl_push_idle+0x40/0x88 dp_bridge_disable+0x24/0x30 drm_atomic_bridge_chain_disable+0x90/0xbc drm_atomic_helper_commit_modeset_disables+0x198/0x444 msm_atomic_commit_tail+0x1d0/0x374 commit_tail+0x80/0x108 drm_atomic_helper_commit+0x118/0x11c drm_atomic_commit+0xb4/0xe0 drm_client_modeset_commit_atomic+0x184/0x224 drm_client_modeset_commit_locked+0x58/0x160 drm_client_modeset_commit+0x3c/0x64 __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac drm_fb_helper_set_par+0x74/0x80 drm_fb_helper_hotplug_event+0xdc/0xe0 __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c drm_fb_helper_lastclose+0x20/0x2c drm_lastclose+0x44/0x6c drm_release+0x88/0xd4 __fput+0x104/0x220 ____fput+0x1c/0x28 task_work_run+0x8c/0x100 d ---truncated---
Modified: 2026-01-14
CVE-2022-50399
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: prevent integer overflow in sh_css_set_black_frame() The "height" and "width" values come from the user so the "height * width" multiplication can overflow.
Modified: 2026-01-20
CVE-2022-50425
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly When an extended state component is not present in fpstate, but in init state, the function copies from init_fpstate via copy_feature(). But, dynamic states are not present in init_fpstate because of all-zeros init states. Then retrieving them from init_fpstate will explode like this: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:memcpy_erms+0x6/0x10 ? __copy_xstate_to_uabi_buf+0x381/0x870 fpu_copy_guest_fpstate_to_uabi+0x28/0x80 kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm] ? __this_cpu_preempt_check+0x13/0x20 ? vmx_vcpu_put+0x2e/0x260 [kvm_intel] kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? __fget_light+0xd4/0x130 __x64_sys_ioctl+0xe3/0x910 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x27/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Adjust the 'mask' to zero out the userspace buffer for the features that are not available both from fpstate and from init_fpstate. The dynamic features depend on the compacted XSAVE format. Ensure it is enabled before reading XCOMP_BV in init_fpstate.
Modified: 2026-01-20
CVE-2022-50427
In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix possible memory leak in snd_ac97_dev_register() If device_register() fails in snd_ac97_dev_register(), it should call put_device() to give up reference, or the name allocated in dev_set_name() is leaked.
- https://git.kernel.org/stable/c/0f8e9a15c8ecf95057061d370a2dddaf1cee4aeb
- https://git.kernel.org/stable/c/4881bda5ea05c8c240fc8afeaa928e2bc43f61fa
- https://git.kernel.org/stable/c/4fdf6f978c6b605ca0d67bf0e982b7a8fc0f4aab
- https://git.kernel.org/stable/c/758dbcc6fbf2286eff02743b093c70a18a407d66
- https://git.kernel.org/stable/c/a602ec9d88f177dba78bc97fb1adecc7a71ff279
- https://git.kernel.org/stable/c/bfce73088682ef0770da951f51156c36a89be490
- https://git.kernel.org/stable/c/c68b2e9ef246117f696e360bbdd2f5736b3a7127
- https://git.kernel.org/stable/c/ee8bf0946f62ef00e5db4b613a9f664ac567259a
Modified: 2026-01-20
CVE-2022-50431
In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev() dev_set_name() in soundbus_add_one() allocates memory for name, it need be freed when of_device_register() fails, call soundbus_dev_put() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. And other resources are also freed in i2sbus_release_dev(), so it can return 0 directly.
- https://git.kernel.org/stable/c/027fee10e3a400cf6f3237374a1248da1082807b
- https://git.kernel.org/stable/c/4a4c8482e370d697738a78dcd7bf2780832cb712
- https://git.kernel.org/stable/c/5bdea674534153110b90d70b02f2fbaf48b2c0eb
- https://git.kernel.org/stable/c/802532a50acf501fdafe38a84ca2aa886d68af68
- https://git.kernel.org/stable/c/c7524279c8ddc7dbf3463bec70e0289097959944
- https://git.kernel.org/stable/c/ce6fd1c382a38b75557db85a2fe99d285540a03d
- https://git.kernel.org/stable/c/e81d7826b8f40430a1ea1b330e24d9a9eb4512c4
- https://git.kernel.org/stable/c/fd410d24665e4efb3c1796797181265efe553e9c
Modified: 2026-01-20
CVE-2022-50432
In the Linux kernel, the following vulnerability has been resolved:
kernfs: fix use-after-free in __kernfs_remove
Syzkaller managed to trigger concurrent calls to
kernfs_remove_by_name_ns() for the same file resulting in
a KASAN detected use-after-free. The race occurs when the root
node is freed during kernfs_drain().
To prevent this acquire an additional reference for the root
of the tree that is removed before calling __kernfs_remove().
Found by syzkaller with the following reproducer (slab_nomerge is
required):
syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0)
r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0)
close(r0)
pipe2(&(0x7f0000000140)={0xffffffffffffffff,
- https://git.kernel.org/stable/c/028cf780743eea79abffa7206b9dcfc080ad3546
- https://git.kernel.org/stable/c/02eb35131050735332658029082f61515b7dfe38
- https://git.kernel.org/stable/c/4abc99652812a2ddf932f137515d5c5a04723538
- https://git.kernel.org/stable/c/4dfd6a477a1525773469feaf3c514b2c0fef76b5
- https://git.kernel.org/stable/c/6f72a3977ba9d0e5491a5c01315204272e7f9c44
- https://git.kernel.org/stable/c/94d2643df1e70a4c310ebb5e2c493eec33df1a06
- https://git.kernel.org/stable/c/af1b57cc39beca203559576b3046094fc9e5eb32
- https://git.kernel.org/stable/c/c78b0dc6fb7fb389d674e491fd376388cdfb1d53
Modified: 2026-01-21
CVE-2022-50437
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502670/
- https://git.kernel.org/stable/c/08c7375fa27a8ceee028868e03ffb3a0db919d44
- https://git.kernel.org/stable/c/3c43f3ec731c233eb84b66199ee76dbf3ec6ecae
- https://git.kernel.org/stable/c/4c1294da6aed1f16d47a417dcfe6602833c3c95c
- https://git.kernel.org/stable/c/9efb45b45ff6254bfd1f1997a06725cb3fc998a5
- https://git.kernel.org/stable/c/a9c1a6991a9b5aa6d0f2cbc9b8c3bf6c4d094dfa
- https://git.kernel.org/stable/c/b48949ab451eaf1e2c04c272c8a9a96a2b56546f
- https://git.kernel.org/stable/c/e8f916b84e4b028ecad6c6472eaad543cc7df806
- https://git.kernel.org/stable/c/ed7f1ff87a4afea1bc220d2ff00a7ce8e61f0b53
Modified: 2026-01-21
CVE-2022-50438
In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix memory leak when reading function table When the input parameter idx meets the expected case option in hinic_dbg_get_func_table(), read_data is not released. Fix it.
Modified: 2026-01-16
CVE-2022-50446
In the Linux kernel, the following vulnerability has been resolved: ARC: mm: fix leakage of memory allocated for PTE Since commit d9820ff ("ARC: mm: switch pgtable_t back to struct page *") a memory leakage problem occurs. Memory allocated for page table entries not released during process termination. This issue can be reproduced by a small program that allocates a large amount of memory. After several runs, you'll see that the amount of free memory has reduced and will continue to reduce after each run. All ARC CPUs are effected by this issue. The issue was introduced since the kernel stable release v5.15-rc1. As described in commit d9820ff after switch pgtable_t back to struct page *, a pointer to "struct page" and appropriate functions are used to allocate and free a memory page for PTEs, but the pmd_pgtable macro hasn't changed and returns the direct virtual address from the PMD (PGD) entry. Than this address used as a parameter in the __pte_free() and as a result this function couldn't release memory page allocated for PTEs. Fix this issue by changing the pmd_pgtable macro and returning pointer to struct page.
Modified: 2026-01-16
CVE-2022-50452
In the Linux kernel, the following vulnerability has been resolved:
net: sched: cake: fix null pointer access issue when cake_init() fails
When the default qdisc is cake, if the qdisc of dev_queue fails to be
inited during mqprio_init(), cake_reset() is invoked to clear
resources. In this case, the tins is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
cake_init()
q->tins = kvcalloc(...) --->failed, q->tins is NULL
...
qdisc_put()
...
cake_reset()
...
cake_dequeue_one()
b = &q->tins[...] --->q->tins is NULL
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:cake_dequeue_one+0xc9/0x3c0
Call Trace:
- https://git.kernel.org/stable/c/154f4c06d9dbec1a14e91286c70b6305810302e0
- https://git.kernel.org/stable/c/1dc0a019550fd38ec6cab2d73c90df2bd659c96b
- https://git.kernel.org/stable/c/51f9a8921ceacd7bf0d3f47fa867a64988ba1dcb
- https://git.kernel.org/stable/c/86aa1390898146f1de277bb6d2a8ed7fc7a43f12
- https://git.kernel.org/stable/c/ae48bee2830bf216800e1447baca39541e27a12e
- https://git.kernel.org/stable/c/bc8301ea7e7f1bb9d2ba2fcdf7b5ec2f0792b47e
Modified: 2026-01-16
CVE-2022-50460
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix xid leak in cifs_flock() If not flock, before return -ENOLCK, should free the xid, otherwise, the xid will be leaked.
Modified: 2026-01-16
CVE-2022-50466
In the Linux kernel, the following vulnerability has been resolved:
fs/binfmt_elf: Fix memory leak in load_elf_binary()
There is a memory leak reported by kmemleak:
unreferenced object 0xffff88817104ef80 (size 224):
comm "xfs_admin", pid 47165, jiffies 4298708825 (age 1333.476s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60 a8 b3 00 81 88 ff ff a8 10 5a 00 81 88 ff ff `.........Z.....
backtrace:
[
Modified: 2026-01-23
CVE-2022-50470
In the Linux kernel, the following vulnerability has been resolved: xhci: Remove device endpoints from bandwidth list when freeing the device Endpoints are normally deleted from the bandwidth list when they are dropped, before the virt device is freed. If xHC host is dying or being removed then the endpoints aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host controller. So check and delete endpoints that are still on the bandwidth list when freeing the virt device. Solves a list_del corruption kernel crash when unbinding xhci-pci, caused by xhci_mem_cleanup() when it later tried to delete already freed endpoints from the bandwidth list. This only affects hosts that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
- https://git.kernel.org/stable/c/3bf860a41e0f2fcea0ac3aae8f7ef887a7994b70
- https://git.kernel.org/stable/c/5aed5b7c2430ce318a8e62f752f181e66f0d1053
- https://git.kernel.org/stable/c/5e4ce28ad907aa54f13b21d5f1dc490525957b0c
- https://git.kernel.org/stable/c/678d2cc2041cc6ce05030852dce9ad42719abcfc
- https://git.kernel.org/stable/c/8f1cd9633d1f21efc13e8fc75be8f2b6bb85e38c
- https://git.kernel.org/stable/c/c892a81c7424b4f6a660cb9c249d354ccf3afeca
- https://git.kernel.org/stable/c/cebbc8d335d6bcc1316584f779c08f80287c6af8
- https://git.kernel.org/stable/c/f0de39474078adef6ece7a183e34c15ce2c1d8d1
Modified: 2026-01-23
CVE-2022-50482
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clean up si_domain in the init_dmars() error path A splat from kmem_cache_destroy() was seen with a kernel prior to commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") when there was a failure in init_dmars(), because the iommu_domain cache still had objects. While the mempool code is now gone, there still is a leak of the si_domain memory if init_dmars() fails. So clean up si_domain in the init_dmars() error path.
- https://git.kernel.org/stable/c/0365d6af75f9f2696e94a0fef24a2c8464c037c8
- https://git.kernel.org/stable/c/5cecfe151874b835331efe086bbdcaeaf64f6b90
- https://git.kernel.org/stable/c/620bf9f981365c18cc2766c53d92bf8131c63f32
- https://git.kernel.org/stable/c/724483b585a1b1e063d42ac5aa835707ff2ec165
- https://git.kernel.org/stable/c/749bea542b67513e99240dc58bbfc099e842d508
- https://git.kernel.org/stable/c/c4ad3ae4c6be9d8b0701761c839771116bca6ea3
- https://git.kernel.org/stable/c/d74196bb278b8f8af88e16bd595997dfa3d6fdb0
Modified: 2026-03-25
CVE-2022-50491
In the Linux kernel, the following vulnerability has been resolved:
coresight: cti: Fix hang in cti_disable_hw()
cti_enable_hw() and cti_disable_hw() are called from an atomic context
so shouldn't use runtime PM because it can result in a sleep when
communicating with firmware.
Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock
management to the SCMI power domain""), this causes a hang on Juno when
running the Perf Coresight tests or running this command:
perf record -e cs_etm//u -- ls
This was also missed until the revert commit because pm_runtime_put()
was called with the wrong device until commit 692c9a499b28 ("coresight:
cti: Correct the parameter for pm_runtime_put")
With lock and scheduler debugging enabled the following is output:
coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti
BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<0000000000000000>] 0x0
hardirqs last disabled at (0): [
Modified: 2026-01-23
CVE-2022-50492
In the Linux kernel, the following vulnerability has been resolved: drm/msm: fix use-after-free on probe deferral The bridge counter was never reset when tearing down the DRM device so that stale pointers to deallocated structures would be accessed on the next tear down (e.g. after a second late bind deferral). Given enough bridges and a few probe deferrals this could currently also lead to data beyond the bridge array being corrupted. Patchwork: https://patchwork.freedesktop.org/patch/502665/
Modified: 2026-01-22
CVE-2022-50500
In the Linux kernel, the following vulnerability has been resolved: netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed If some items in nsim_dev_resources_register() fail, memory leak will occur. The following is the memory leak information. unreferenced object 0xffff888074c02600 (size 128): comm "echo", pid 8159, jiffies 4294945184 (age 493.530s) hex dump (first 32 bytes): 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<0000000011a31c98>] kmalloc_trace+0x22/0x60 [<0000000027384c69>] devl_resource_register+0x144/0x4e0 [<00000000a16db248>] nsim_drv_probe+0x37a/0x1260 [<000000007d1f448c>] really_probe+0x20b/0xb10 [<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0 [<00000000077e0351>] driver_probe_device+0x49/0x140 [<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0 [<000000008538f359>] bus_for_each_drv+0x151/0x1d0 [<0000000038e09747>] __device_attach+0x1c9/0x4e0 [<00000000dd86e533>] bus_probe_device+0x1d5/0x280 [<00000000839bea35>] device_add+0xae0/0x1cb0 [<000000009c2abf46>] new_device_store+0x3b6/0x5f0 [<00000000fb823d7f>] bus_attr_store+0x72/0xa0 [<000000007acc4295>] sysfs_kf_write+0x106/0x160 [<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0 [<0000000075eb41bf>] vfs_write+0x8f0/0xc80
Modified: 2026-03-25
CVE-2022-50506
In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a bio_set_dev call (which has since been removed) to "earlier", from drbd_request_prepare to drbd_req_new. The problem is that this accesses device->ldev->backing_bdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref. So, only allocate the private_bio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case.
Modified: 2026-03-17
CVE-2022-50517
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: do not clobber swp_entry_t during THP split
The following has been observed when running stressng mmap since commit
b653db77350c ("mm: Clear page->private when splitting or migrating a page")
watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546]
CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374
Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016
RIP: 0010:xas_descend+0x28/0x80
Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2
RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246
RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002
RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0
RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0
R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000
R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88
FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
Modified: 2026-03-17
CVE-2022-50526
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502664/
Modified: 2026-03-17
CVE-2022-50530
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping() Our syzkaller report a null pointer dereference, root cause is following: __blk_mq_alloc_map_and_rqs set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs blk_mq_alloc_map_and_rqs blk_mq_alloc_rqs // failed due to oom alloc_pages_node // set->tags[hctx_idx] is still NULL blk_mq_free_rqs drv_tags = set->tags[hctx_idx]; // null pointer dereference is triggered blk_mq_clear_rq_mapping(drv_tags, ...) This is because commit 63064be150e4 ("blk-mq: Add blk_mq_alloc_map_and_rqs()") merged the two steps: 1) set->tags[hctx_idx] = blk_mq_alloc_rq_map() 2) blk_mq_alloc_rqs(..., set->tags[hctx_idx]) into one step: set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs() Since tags is not initialized yet in this case, fix the problem by checking if tags is NULL pointer in blk_mq_clear_rq_mapping().
Modified: 2026-03-17
CVE-2022-50531
In the Linux kernel, the following vulnerability has been resolved: tipc: fix an information leak in tipc_topsrv_kern_subscr Use a 8-byte write to initialize sub.usr_handle in tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized when issuing setsockopt(..., SOL_TIPC, ...). This resulted in an infoleak reported by KMSAN when the packet was received: ===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169 instrument_copy_to_user ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/iov_iter.c:169 _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527 copy_to_iter ./include/linux/uio.h:176 simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419 skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527 skb_copy_datagram_msg ./include/linux/skbuff.h:3903 packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469 ____sys_recvmsg+0x2c4/0x810 net/socket.c:? ___sys_recvmsg+0x217/0x840 net/socket.c:2743 __sys_recvmsg net/socket.c:2773 __do_sys_recvmsg net/socket.c:2783 __se_sys_recvmsg net/socket.c:2780 __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 ... Uninit was stored to memory at: tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375 tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084 tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201 __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 __se_sys_setsockopt net/socket.c:2260 __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 Local variable sub created at: tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================
- https://git.kernel.org/stable/c/3d1b83ff7b6575a4e41283203e6b2e25ea700cd7
- https://git.kernel.org/stable/c/567f8de358b61015dcfb8878a1f06c5369a45f54
- https://git.kernel.org/stable/c/777ecaabd614d47c482a5c9031579e66da13989a
- https://git.kernel.org/stable/c/dbc01c0a4e202a7e925dad1d4b7c1d6eb0c81154
- https://git.kernel.org/stable/c/e558e148938442dd49628cd7ef61c360832bef31
- https://git.kernel.org/stable/c/fef70f978bc289642501d88d2a3f5e841bd31a67
Modified: 2026-02-05
CVE-2022-50555
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a null-ptr-deref in tipc_topsrv_accept
syzbot found a crash in tipc_topsrv_accept:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
Workqueue: tipc_rcv tipc_topsrv_accept
RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487
Call Trace:
- https://git.kernel.org/stable/c/24b129aed8730e48f47d852d58d76825ab6f407c
- https://git.kernel.org/stable/c/32a3d4660b34ce49ac0162338ebe362098e2f5df
- https://git.kernel.org/stable/c/7a939503fc32bff4ed60800b73ff7fbb4aea2142
- https://git.kernel.org/stable/c/82cb4e4612c633a9ce320e1773114875604a3cce
- https://git.kernel.org/stable/c/ce69bdac2310152bb70845024d5d704c52aabfc3
- https://git.kernel.org/stable/c/cedb41664e27b2cae7e21487f1bee22dcd84037d
Modified: 2024-11-21
CVE-2023-3812
An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
Package kernel-image-std-kvm updated to version 5.10.154-alt1 for branch sisyphus in task 309872.
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-06550
Уязвимость функции l2cap_conn_del() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2024-09-30
BDU:2022-06564
Уязвимость функции l2cap_reassemble_sdu() (net/bluetooth/l2cap_core.c) ядра операционных систем Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-06620
Уязвимость функции del_timer компонента drivers/isdn/mISDN/l1oip_core.c ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код
Modified: 2025-08-19
BDU:2022-07074
Уязвимость функций l2cap_connect и l2cap_le_connect_req (net/bluetooth/l2cap_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: 2026-01-20
BDU:2023-04465
Уязвимость функции tun_napi_alloc_frags() в модуле drivers/net/tun.c драйвера TUN/TAP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2024-09-30
BDU:2023-07631
Уязвимость драйвера файловой системы NILFS ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-11-18
BDU:2024-04235
Уязвимость функции amu_fie_setup() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-01-20
BDU:2024-08405
Уязвимость компонента inet ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-03-18
BDU:2025-01976
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-10255
Уязвимость ядра операционной системы 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:2026-01283
Уязвимость функции btrfs_quota_enable() модуля fs/btrfs/qgroup.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-01285
Уязвимость функции kernfs_remove_by_name_ns() модуля fs/kernfs/dir.c файловой системы ядра операционной системы 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-02177
Уязвимость функции sata_pmp_init_links() в модуле drivers/ata/libata-pmp.c ядра операционной системы 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-02372
Уязвимость функции msm_dsi_modeset_init() модуля drivers/gpu/drm/msm/dsi/dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02433
Уязвимость функции ge_b850v3_lvds_remove() модуля drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02434
Уязвимость функции hnae_ae_register() модуля drivers/net/ethernet/hisilicon/hns/hnae.c драйвера сетевых адаптеров Ethernet Hisilicon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02435
Уязвимость функции sfb_reset() модуля net/sched/sch_sfb.c подсистемы управления трафиком net/sched ядра операционной системы 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-02638
Уязвимость функции make_indexed_dir() в модуле fs/ext4/namei.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02639
Уязвимость функции ext4_ext_migrate() в модуле fs/ext4/migrate.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03265
Уязвимость функции snd_pcm_oss_sync() модуля sound/core/oss/pcm_oss.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03639
Уязвимость функции ip_vs_app_net_cleanup() модуля net/netfilter/ipvs/ip_vs_app.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03730
Уязвимость функции piix4_probe() модуля drivers/i2c/busses/i2c-piix4.c драйвера аппаратной шины I2C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03731
Уязвимость функций l2cap_rx_state_recv() и l2cap_rx() модуля net/bluetooth/l2cap_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03732
Уязвимость функций test_no_shared_qgroup() и test_multiple_refs() модуля fs/btrfs/tests/qgroup-tests.c файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03733
Уязвимость функций prelim_release() и find_parent_nodes() модуля fs/btrfs/backref.c файловой системы btrfs ядра операционной системы 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-03828
Уязвимость функции tipc_topsrv_kern_subscr() модуля net/tipc/topsrv.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03838
Уязвимость функции cifs_flock() модуля fs/cifs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03843
Уязвимость функции pl353_smc_probe() модуля drivers/memory/pl353-smc.c драйвера контроллера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03975
Уязвимость функции __mdiobus_register() модуля drivers/net/phy/mdio_bus.c драйвера сети физического уровня (PHY) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-04052
Уязвимость функции snd_ac97_dev_register() модуля sound/pci/ac97/ac97_codec.c звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04055
Уязвимость функции i2sbus_add_dev() модуля sound/aoa/soundbus/i2sbus/core.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-05735
Уязвимость функции alloc_huge_page() модуля mm/hugetlb.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05779
Уязвимость функций test_gen_kprobe/kretprobe_cmd() и test_gen_kprobe_cmd() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05780
Уязвимость функций __ip_vs_cleanup_batch() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05847
Уязвимость функции mISDN_register_device() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05848
Уязвимость функции red_enqueue() ядра операционной системы 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-05978
Уязвимость функции hinic_init_cmdqs() модуля drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06050
Уязвимость функции sc_disable() ядра операционных систем Linux, позволяющая нарушителю вызвать сбой ядра
BDU:2026-06051
Уязвимость функции nf_flow_table_free() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06069
Уязвимость функции qcom_cpufreq_probe() в модуле drivers/cpufreq/qcom-cpufreq-nvmem.c драйвера масштабирования частоты ЦП ядра операционной системы 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, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06084
Уязвимость функции hinic_dbg_get_func_table() в модуле drivers/net/ethernet/huawei/hinic/hinic_debugfs.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06089
Уязвимость функции cake_dequeue() в модуле net/sched/sch_cake.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06092
Уязвимость функции load_elf_binary() в модуле fs/binfmt_elf.c файловой системы ядра операционной системы 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-3564
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_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 associated identifier of this vulnerability is VDB-211087.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://security.netapp.com/advisory/ntap-20221223-0001/
- https://vuldb.com/?id.211087
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-3640
A vulnerability, which was classified as critical, was found in Linux Kernel. Affected is the function l2cap_conn_del of the file net/bluetooth/l2cap_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-211944.
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
- https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=42cf46dea905a80f6de218e837ba4d4cc33d6979
- https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html
- https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DGOIRR72OAFE53XZRUDZDP7INGLIC3E3/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OD7VWUT7YAU4CJ247IF44NGVOAODAJGC/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XG2UPX3MQ7RKRJEUMGEH2TLPKZJCBU5C/
- https://vuldb.com/?id.211944
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: 2024-11-21
CVE-2022-42896
There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim. We recommend upgrading past commit https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url
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: 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: 2025-10-01
CVE-2022-49035
In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case.
- https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c
- https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4
- https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39
- https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a
- https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968964b26c
- https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11
- https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd
- https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c
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-10
CVE-2022-49879
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix BUG_ON() when directory entry has invalid rec_len
The rec_len field in the directory entry has to be a multiple of 4. A
corrupted filesystem image can be used to hit a BUG() in
ext4_rec_len_to_disk(), called from make_indexed_dir().
------------[ cut here ]------------
kernel BUG at fs/ext4/ext4.h:2413!
...
RIP: 0010:make_indexed_dir+0x53f/0x5f0
...
Call Trace:
- https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad
- https://git.kernel.org/stable/c/17a0bc9bd697f75cfdf9b378d5eb2d7409c91340
- https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909
- https://git.kernel.org/stable/c/999cff2b6ce3b45c08abf793bf55534777421327
- https://git.kernel.org/stable/c/ce1ee2c8827fb6493e91acbd50f664cf2a972c3d
Modified: 2025-10-01
CVE-2022-49880
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix warning in 'ext4_da_release_space'
Syzkaller report issue as follows:
EXT4-fs (loop0): Free/Dirty block details
EXT4-fs (loop0): free_blocks=0
EXT4-fs (loop0): dirty_blocks=0
EXT4-fs (loop0): Block reservation details
EXT4-fs (loop0): i_reserved_data_blocks=0
EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
------------[ cut here ]------------
WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
Modules linked in:
CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: writeback wb_workfn (flush-7:0)
RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883
- https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb
- https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b
- https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e
- https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97
- https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20
- https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6
- https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63
Modified: 2025-10-01
CVE-2022-49885
In the Linux kernel, the following vulnerability has been resolved:
ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init()
Change num_ghes from int to unsigned int, preventing an overflow
and causing subsequent vmalloc() to fail.
The overflow happens in ghes_estatus_pool_init() when calculating
len during execution of the statement below as both multiplication
operands here are signed int:
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
The following call trace is observed because of this bug:
[ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1
[ 9.317131] Call Trace:
[ 9.317134]
Modified: 2025-10-01
CVE-2022-49887
In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix possible refcount leak in vdec_probe() v4l2_device_unregister need to be called to put the refcount got by v4l2_device_register when vdec_probe fails or vdec_remove is called.
- https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef
- https://git.kernel.org/stable/c/70119756311a0be3b95bec2e1ba714673e90feba
- https://git.kernel.org/stable/c/7718999356234d9cc6a11b4641bb773928f1390f
- https://git.kernel.org/stable/c/be6e22f54623d8a856a4f167b25be73c2ff1ff80
- https://git.kernel.org/stable/c/f96ad391d054bd5c36994f98afd6a12cbb5600bf
Modified: 2025-10-01
CVE-2022-49890
In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks]
- https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603
- https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1
- https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85
- https://git.kernel.org/stable/c/7480aeff0093d8c54377553ec6b31110bea37b4d
- https://git.kernel.org/stable/c/8cf0a1bc12870d148ae830a4ba88cfdf0e879cee
- https://git.kernel.org/stable/c/90577bcc01c4188416a47269f8433f70502abe98
- https://git.kernel.org/stable/c/cdf01c807e974048c43c7fd3ca574f6086a57906
Modified: 2025-10-01
CVE-2022-49891
In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd() test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd(). unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
Modified: 2025-05-07
CVE-2022-49892
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...]
Modified: 2025-10-01
CVE-2022-49899
In the Linux kernel, the following vulnerability has been resolved: fscrypt: stop using keyrings subsystem for fscrypt_master_key The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support.
Modified: 2025-11-10
CVE-2022-49900
In the Linux kernel, the following vulnerability has been resolved:
i2c: piix4: Fix adapter not be removed in piix4_remove()
In piix4_probe(), the piix4 adapter will be registered in:
piix4_probe()
piix4_add_adapters_sb800() / piix4_add_adapter()
i2c_add_adapter()
Based on the probed device type, piix4_add_adapters_sb800() or single
piix4_add_adapter() will be called.
For the former case, piix4_adapter_count is set as the number of adapters,
while for antoher case it is not set and kept default *zero*.
When piix4 is removed, piix4_remove() removes the adapters added in
piix4_probe(), basing on the piix4_adapter_count value.
Because the count is zero for the single adapter case, the adapter won't
be removed and makes the sources allocated for adapter leaked, such as
the i2c client and device.
These sources can still be accessed by i2c or bus and cause problems.
An easily reproduced case is that if a new adapter is registered, i2c
will get the leaked adapter and try to call smbus_algorithm, which was
already freed:
Triggered by: rmmod i2c_piix4 && modprobe max31730
BUG: unable to handle page fault for address: ffffffffc053d860
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 3752 Comm: modprobe Tainted: G
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core
RSP: 0018:ffff888107477710 EFLAGS: 00000246
...
Modified: 2025-11-11
CVE-2022-49903
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix WARNING in ip6_route_net_exit_late()
During the initialization of ip6_route_net_init_late(), if file
ipv6_route or rt6_stats fails to be created, the initialization is
successful by default. Therefore, the ipv6_route or rt6_stats file
doesn't be found during the remove in ip6_route_net_exit_late(). It
will cause WRNING.
The following is the stack information:
name 'rt6_stats'
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
PKRU: 55555554
Call Trace:
- https://git.kernel.org/stable/c/080589287127838046077904f34d5054ea0f895c
- https://git.kernel.org/stable/c/0ed71af4d017d2bd2cbb8f7254f613a4914def26
- https://git.kernel.org/stable/c/381453770f731f0f43616a1cd4c759b7807a1517
- https://git.kernel.org/stable/c/5dbb47ee89762da433cd8458788d7640c85f1a07
- https://git.kernel.org/stable/c/768b3c745fe5789f2430bdab02f35a9ad1148d97
- https://git.kernel.org/stable/c/83fbf246ced54dadd7b9adc2a16efeff30ba944d
Modified: 2025-10-01
CVE-2022-49904
In the Linux kernel, the following vulnerability has been resolved:
net, neigh: Fix null-ptr-deref in neigh_table_clear()
When IPv6 module gets initialized but hits an error in the middle,
kenel panic with:
KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
CPU: 1 PID: 361 Comm: insmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
RSP: 0018:ffff888012677908 EFLAGS: 00000202
...
Call Trace:
- https://git.kernel.org/stable/c/0d38b4ca6679e72860ff8730e79bb99d0e9fa3b0
- https://git.kernel.org/stable/c/1c89642e7f2b7ecc9635610653f5c2f0276c0051
- https://git.kernel.org/stable/c/2b45d6d0c41cb9593868e476681efb1aae5078a1
- https://git.kernel.org/stable/c/a99a8ec4c62180c889482a2ff6465033e0743458
- https://git.kernel.org/stable/c/b49f6b2f21f543d4dc88fb7b1ec2adccb822f27c
- https://git.kernel.org/stable/c/b736592de2aa53aee2d48d6b129bc0c892007bbe
- https://git.kernel.org/stable/c/f8017317cb0b279b8ab98b0f3901a2e0ac880dad
Modified: 2025-11-11
CVE-2022-49907
In the Linux kernel, the following vulnerability has been resolved:
net: mdio: fix undefined behavior in bit shift for __mdiobus_register
Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned. The UBSAN warning calltrace like below:
UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
left shift of 1 by 31 places cannot be represented in type 'int'
Call Trace:
- https://git.kernel.org/stable/c/20ed01a7b9af6e6a3c33761eebbb710ea6dd49b7
- https://git.kernel.org/stable/c/40e4eb324c59e11fcb927aa46742d28aba6ecb8a
- https://git.kernel.org/stable/c/4954b5359eb141499492fadfab891e28905509e2
- https://git.kernel.org/stable/c/634f066d02bdb22a26da7deb0c7617ab1a65fc9d
- https://git.kernel.org/stable/c/6ce6f8f8f6316da6f92afe7490bc2f0b654d68e0
- https://git.kernel.org/stable/c/7006176a3c863e3e353ce1b8a349ef5bb1b9320e
- https://git.kernel.org/stable/c/985a88bf0b27193522bba7856b1763f428cef19d
- https://git.kernel.org/stable/c/a3fafc974be37319679f36dc4e7cca7db1e02973
Modified: 2025-11-11
CVE-2022-49910
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
Fix the race condition between the following two flows that run in
parallel:
1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
__sock_queue_rcv_skb.
2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).
Fix it by keeping a local copy of struct l2cap_ctrl.
BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
- https://git.kernel.org/stable/c/03af22e23b96fb7ef75fb7885407ef457e8b403d
- https://git.kernel.org/stable/c/3aff8aaca4e36dc8b17eaa011684881a80238966
- https://git.kernel.org/stable/c/4cd094fd5d872862ca278e15b9b51b07e915ef3f
- https://git.kernel.org/stable/c/6c7407bfbeafc80a04e6eaedcf34d378532a04f2
- https://git.kernel.org/stable/c/8278a87bb1eeea94350d675ef961ee5a03341fde
- https://git.kernel.org/stable/c/9a04161244603f502c6e453913e51edd59cb70c1
- https://git.kernel.org/stable/c/cb1c012099ef5904cd468bdb8d6fcdfdd9bcb569
- https://git.kernel.org/stable/c/dc30e05bb18852303084430c03ca76e69257d9ea
Modified: 2025-11-12
CVE-2022-49912
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ulist leaks in error paths of qgroup self tests In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests, if we fail to add the tree ref, remove the extent item or remove the extent ref, we are returning from the test function without freeing the "old_roots" ulist that was allocated by the previous calls to btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
- https://git.kernel.org/stable/c/0a0dead4ad1a2e2a9bdf133ef45111d7c8daef84
- https://git.kernel.org/stable/c/203204798831c35d855ecc6417d98267d2d2184b
- https://git.kernel.org/stable/c/3f58283d83a588ff5da62fc150de19e798ed2ec2
- https://git.kernel.org/stable/c/5d1a47ebf84540e40b5b43fc21aef0d6c0f627d9
- https://git.kernel.org/stable/c/d37de92b38932d40e4a251e876cc388f9aee5f42
- https://git.kernel.org/stable/c/d81370396025cf63a7a1b5f8bb25a3479203b2ca
- https://git.kernel.org/stable/c/da7003434bcab0ae9aba3f2c003e734cae093326
- https://git.kernel.org/stable/c/f46ea5fa3320dca4fe0c0926b49a5f14cb85de62
Modified: 2025-11-12
CVE-2022-49913
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at find_parent_nodes() During backref walking, at find_parent_nodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolve_indirect_refs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to the refs ulist passed as argument to find_parent_nodes(). Since they were not yet added to the refs ulist and prelim_release() does not free the lists, on error the caller can only free the lists attached to the refs that were added to the refs ulist, all the remaining refs get their inode lists never freed, therefore leaking their memory. Fix this by having prelim_release() always free any attached inode list to each ref found in the rbtree, and have find_parent_nodes() set the ref's inode list to NULL once it transfers ownership of the inode list to a ref added to the refs ulist passed to find_parent_nodes().
- https://git.kernel.org/stable/c/222a3d533027b9492d5b7f5ecdc01a90f57bb5a9
- https://git.kernel.org/stable/c/61e06128113711df0534c404fb6bb528eb7d2332
- https://git.kernel.org/stable/c/6a6731a0df8c47ecc703bd7bb73459df767051e0
- https://git.kernel.org/stable/c/83ea8c5b54d452a5769e605e3c5c687e8ca06d89
- https://git.kernel.org/stable/c/92876eec382a0f19f33d09d2c939e9ca49038ae5
Modified: 2025-11-12
CVE-2022-49914
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the unodes. Fix this by calling free_leaf_list() instead of ulist_free() when we exit from resolve_indirect_refs(). The static function free_leaf_list() is moved up for this to be possible and it's slightly simplified by removing unnecessary code.
- https://git.kernel.org/stable/c/2c0329406bb28109c07c6e23e5e3e0fa618a95d7
- https://git.kernel.org/stable/c/396515db923ad5cbeb179d6b88927870b4cbebb7
- https://git.kernel.org/stable/c/5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1
- https://git.kernel.org/stable/c/6ba3479f9e96b9ad460c7e77abc26dd16e5dec4f
- https://git.kernel.org/stable/c/a52e24c7fcc3c5ce3588a14e3663c00868d36623
- https://git.kernel.org/stable/c/b1dc9019bb5f89abae85645de1a2dd4830c1f8e9
- https://git.kernel.org/stable/c/cded2c89774b99b67c98147ae103ea878c92a206
Modified: 2025-10-01
CVE-2022-49915
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release().
- https://git.kernel.org/stable/c/029d5b7688a2f3a86f2a3be5a6ba9cc968c80e41
- https://git.kernel.org/stable/c/080aabfb29b2ee9cbb8894a1d039651943d3773e
- https://git.kernel.org/stable/c/0d4e91efcaee081e919b3c50e875ecbb84290e41
- https://git.kernel.org/stable/c/2ff6b669523d3b3d253a044fa9636a67d0694995
- https://git.kernel.org/stable/c/a636fc5a7cabd05699b5692ad838c2c7a3abec7b
- https://git.kernel.org/stable/c/d1d1aede313eb2b9a84afd60ff6cfb7c33631e0e
- https://git.kernel.org/stable/c/e77d213843e67b4373285712699b692f9c743f61
- https://git.kernel.org/stable/c/e7d1d4d9ac0dfa40be4c2c8abd0731659869b297
Modified: 2025-10-01
CVE-2022-49916
In the Linux kernel, the following vulnerability has been resolved:
rose: Fix NULL pointer dereference in rose_send_frame()
The syzkaller reported an issue:
KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Workqueue: rcu_gp srcu_invoke_callbacks
RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
Call Trace:
- https://git.kernel.org/stable/c/01b9c68c121847d05a4ccef68244dadf82bfa331
- https://git.kernel.org/stable/c/3e2129c67daca21043a26575108f6286c85e71f6
- https://git.kernel.org/stable/c/5b46adfbee1e429f33b10a88d6c00fa88f3d6c77
- https://git.kernel.org/stable/c/a601e5eded33bb88b8a42743db8fef3ad41dd97e
- https://git.kernel.org/stable/c/b13be5e852b03f376058027e462fad4230240891
- https://git.kernel.org/stable/c/bbc03d74e641e824754443b908454ca9e203773e
- https://git.kernel.org/stable/c/e97c089d7a49f67027395ddf70bf327eeac2611e
- https://git.kernel.org/stable/c/f06186e5271b980bac03f5c97276ed0146ddc9b0
Modified: 2025-11-12
CVE-2022-49917
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in ip_vs_app_net_cleanup()
During the initialization of ip_vs_app_net_init(), if file ip_vs_app
fails to be created, the initialization is successful by default.
Therefore, the ip_vs_app file doesn't be found during the remove in
ip_vs_app_net_cleanup(). It will cause WRNING.
The following is the stack information:
name 'ip_vs_app'
WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/06d7596d18725f1a93cf817662d36050e5afb989
- https://git.kernel.org/stable/c/2c8d81bdb2684d53d6cedad7410ba4cf9090e343
- https://git.kernel.org/stable/c/5663ed63adb9619c98ab7479aa4606fa9b7a548c
- https://git.kernel.org/stable/c/8457a00c981fe1a799ce34123908856b0f5973b8
- https://git.kernel.org/stable/c/97f872b00937f2689bff2dab4ad9ed259482840f
- https://git.kernel.org/stable/c/adc76740ccd52e4a1d910767cd1223e134a7078b
Modified: 2025-11-12
CVE-2022-49918
In the Linux kernel, the following vulnerability has been resolved:
ipvs: fix WARNING in __ip_vs_cleanup_batch()
During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
or ip_vs_conn_sync fails to be created, the initialization is successful
by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
be found during the remove.
The following is the stack information:
name 'ip_vs_conn_sync'
WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
remove_proc_entry+0x389/0x460
Modules linked in:
Workqueue: netns cleanup_net
RIP: 0010:remove_proc_entry+0x389/0x460
Call Trace:
- https://git.kernel.org/stable/c/3d00c6a0da8ddcf75213e004765e4a42acc71d5d
- https://git.kernel.org/stable/c/5ee2d6b726b0ce339e36569e5849692f4cf4595e
- https://git.kernel.org/stable/c/7effc4ce3d1434ce6ff286866585a6e905fdbfc1
- https://git.kernel.org/stable/c/931f56d59c854263b32075bfac56fdb3b1598d1b
- https://git.kernel.org/stable/c/e724220b826e008764309d2a1f55a9434a4e1530
- https://git.kernel.org/stable/c/f08ee2aa24c076f81d84e26e213d8c6f4efd9f50
Modified: 2025-10-01
CVE-2022-49919
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flow rule object from commit path No need to postpone this to the commit release path, since no packets are walking over this object, this is accessed from control plane only. This helped uncovered UAF triggered by races with the netlink notifier.
- https://git.kernel.org/stable/c/26b5934ff4194e13196bedcba373cd4915071d0e
- https://git.kernel.org/stable/c/4ab6f96444e936f5e4a936d5c0bc948144bcded3
- https://git.kernel.org/stable/c/6044791b7be707fd0e709f26e961a446424e5051
- https://git.kernel.org/stable/c/74fd5839467054cd9c4d050614d3ee8788386171
- https://git.kernel.org/stable/c/b2d7a92aff0fbd93c29d2aa6451fb99f050e2c4e
Modified: 2025-10-01
CVE-2022-49921
In the Linux kernel, the following vulnerability has been resolved: net: sched: Fix use after free in red_enqueue() We can't use "skb" again after passing it to qdisc_enqueue(). This is basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb len before calling child enqueue").
- https://git.kernel.org/stable/c/170e5317042c302777ed6d59fdb84af9b0219d4e
- https://git.kernel.org/stable/c/52e0429471976785c155bfbf51d80990c6cd46e2
- https://git.kernel.org/stable/c/5960b9081baca85cc7dcb14aec1de85999ea9d36
- https://git.kernel.org/stable/c/795afe0b9bb6c915f0299a8e309936519be01619
- https://git.kernel.org/stable/c/8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9
- https://git.kernel.org/stable/c/a238cdcf2bdc72207c74375fc8be13ee549ca9db
- https://git.kernel.org/stable/c/e877f8fa49fbccc63cb2df2e9179bddc695b825a
- https://git.kernel.org/stable/c/fc4b50adb400ee5ec527a04073174e8e73a139fa
Modified: 2025-10-01
CVE-2022-49922
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds.
- https://git.kernel.org/stable/c/52438e734c1566f5e2bcd9a065d2d65e306c0555
- https://git.kernel.org/stable/c/5dfdac5e3f8db5f4445228c44f64091045644a3b
- https://git.kernel.org/stable/c/825656ae61e73ddc05f585e6258d284c87064b10
- https://git.kernel.org/stable/c/92a1df9c6da20c02cf9872f8b025a66ddb307aeb
- https://git.kernel.org/stable/c/93d904a734a74c54d945a9884b4962977f1176cd
- https://git.kernel.org/stable/c/c8e7d4a1166f063703955f1b2e765a6db5bf1771
- https://git.kernel.org/stable/c/dd0ee55ead91fbb16889dbe7ff0b0f7c9e4e849d
- https://git.kernel.org/stable/c/f30060efcf18883748a0541aa41acef183cd9c0e
Modified: 2025-10-01
CVE-2022-49923
In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds.
Modified: 2025-10-01
CVE-2022-49924
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished.
Modified: 2025-10-01
CVE-2022-49925
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
- https://git.kernel.org/stable/c/07c0d131cc0fe1f3981a42958fc52d573d303d89
- https://git.kernel.org/stable/c/6b3d5dcb12347f3518308c2c9d2cf72453a3e1e5
- https://git.kernel.org/stable/c/ab817f75e5e0fa58d9be0825da6a7b7d8a1fa1d9
- https://git.kernel.org/stable/c/af8fb5a0600e9ae29950e9422a032c3c22649ee5
- https://git.kernel.org/stable/c/d360e875c011a005628525bf290322058927e7dc
Modified: 2025-10-01
CVE-2022-49926
In the Linux kernel, the following vulnerability has been resolved: net: dsa: Fix possible memory leaks in dsa_loop_init() kmemleak reported memory leaks in dsa_loop_init(): kmemleak: 12 new suspected memory leaks unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ... There are two reasons for memleak in dsa_loop_init(). First, fixed_phy_register() create and register phy_device: fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove() But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked. Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs. Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.
- https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e
- https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254
- https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50
- https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3
- https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7
- https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f
- https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c
Modified: 2025-10-01
CVE-2022-49927
In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d
- https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67
- https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593
- https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c
- https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d
- https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127
- https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb
- https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401
Modified: 2025-10-01
CVE-2022-49931
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list.
- https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55
- https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e
- https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0
- https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c
- https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926
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-24
CVE-2022-50239
In the Linux kernel, the following vulnerability has been resolved: cpufreq: qcom: fix writes in read-only memory region This commit fixes a kernel oops because of a write in some read-only memory: [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271] __memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190 [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c ..snip.. The following line defines a pointer that point to a char buffer stored in read-only memory: char *pvs_name = "speedXX-pvsXX-vXX"; This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the XX values get overridden by the qcom_cpufreq_krait_name_version function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops: snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the stack by using the following syntax: char pvs_name_buffer[] = "speedXX-pvsXX-vXX"; Because the `pvs_name` needs to be able to be assigned to NULL, the template buffer is stored in the pvs_name_buffer and not under the pvs_name variable.
Modified: 2025-11-24
CVE-2022-50240
In the Linux kernel, the following vulnerability has been resolved: android: binder: stop saving a pointer to the VMA Do not record a pointer to a VMA outside of the mmap_lock for later use. This is unsafe and there are a number of failure paths *after* the recorded VMA pointer may be freed during setup. There is no callback to the driver to clear the saved pointer from generic mm code. Furthermore, the VMA pointer may become stale if any number of VMA operations end up freeing the VMA so saving it was fragile to being with. Instead, change the binder_alloc struct to record the start address of the VMA and use vma_lookup() to get the vma when needed. Add lockdep mmap_lock checks on updates to the vma pointer to ensure the lock is held and depend on that lock for synchronization of readers and writers - which was already the case anyways, so the smp_wmb()/smp_rmb() was not necessary. [akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c]
- https://git.kernel.org/stable/c/015ac18be7de25d17d6e5f1643cb3b60bfbe859e
- https://git.kernel.org/stable/c/1ec3f76a436d750fd5023caec5da0494fc2870d2
- https://git.kernel.org/stable/c/27a594bc7a7c8238d239e3cdbcf2edfa3bbe9a1b
- https://git.kernel.org/stable/c/622ef885a89ad04cfb76ee478fb44f051125d1f1
- https://git.kernel.org/stable/c/925e6b6f82c9c80ab3c17acbde8d16f349da7d26
- https://git.kernel.org/stable/c/a43cfc87caaf46710c8027a8c23b8a55f1078f19
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-11-25
CVE-2022-50257
In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: Prevent leaking grants Prior to this commit, if a grant mapping operation failed partially, some of the entries in the map_ops array would be invalid, whereas all of the entries in the kmap_ops array would be valid. This in turn would cause the following logic in gntdev_map_grant_pages to become invalid: for (i = 0; i < map->count; i++) { if (map->map_ops[i].status == GNTST_okay) { map->unmap_ops[i].handle = map->map_ops[i].handle; if (!use_ptemod) alloced++; } if (use_ptemod) { if (map->kmap_ops[i].status == GNTST_okay) { if (map->map_ops[i].status == GNTST_okay) alloced++; map->kunmap_ops[i].handle = map->kmap_ops[i].handle; } } } ... atomic_add(alloced, &map->live_grants); Assume that use_ptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the "alloced" variable is only incremented when both kmap_ops[i].status and map_ops[i].status are set to GNTST_okay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above. The aforementioned causes map->live_grants to be incorrectly set. In some cases, all of the map_ops mappings fail, but all of the kmap_ops mappings succeed, meaning that live_grants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmap_ops, because unmap_grant_pages has the following snippet of code at its beginning: if (atomic_read(&map->live_grants) == 0) return; /* Nothing to do */ In other cases where only some of the map_ops mappings fail but all kmap_ops mappings succeed, live_grants is made positive, but when the user requests unmapping the grant-mapped pages, __unmap_grant_pages_done will then make map->live_grants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts "data->count" (i.e., a value that can be greater than map->live_grants) from map->live_grants. The side effects of a negative live_grants value have not been studied. The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen's grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: "g.e. 0x1234 still pending", especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0). The fix for this issue involves counting all successful map_ops and kmap_ops mappings separately, and then adding the sum to live_grants. During unmapping, only the number of successfully unmapped grants is subtracted from live_grants. The code is also modified to check for negative live_grants values after the subtraction and warn the user.
- https://git.kernel.org/stable/c/0991028cd49567d7016d1b224fe0117c35059f86
- https://git.kernel.org/stable/c/0bccddd9b8f03ad57bb738f0d3da8845d4e1e579
- https://git.kernel.org/stable/c/1cb73704cb4778299609634a790a80daba582f7d
- https://git.kernel.org/stable/c/273f6a4f71be12e2ec80a4919837d6e4fa933a04
- https://git.kernel.org/stable/c/3d056d81b93a787613eda44aeb21fc14c3392b34
- https://git.kernel.org/stable/c/49bb053b1ec367b6883030eb2cca696e91435679
- https://git.kernel.org/stable/c/49db6cb81400ba863e1a85e55fcdf1031807c23f
- https://git.kernel.org/stable/c/b043f2cab100bed3e0a999dcf38cc05b1e4a7e41
- https://git.kernel.org/stable/c/cb1ccfe7655380f77a58b340072f5f40bc285902
Modified: 2025-12-03
CVE-2022-50265
In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_wait kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. syzbot reported: BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: reserve_rx_kcm net/kcm/kcmsock.c:283 [inline] kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x01 -> 0x00 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
- https://git.kernel.org/stable/c/0c745b5141a45a076f1cb9772a399f7ebcb0948a
- https://git.kernel.org/stable/c/2733fb2ad5bfbe6538f2f93a21f2504e3dba9d6a
- https://git.kernel.org/stable/c/62086d1c4602e4f2ec07b975165afc2ed0ff1be9
- https://git.kernel.org/stable/c/663682cd3192dd4f3547b7890a4391c72441001d
- https://git.kernel.org/stable/c/9ae47f11493509cde707af8ecc7eee04c8b8e635
- https://git.kernel.org/stable/c/dbc3a0b917c4f75292b1c0819c188e40fd3c8924
- https://git.kernel.org/stable/c/e2a28807b1ceaa309164b92c38d73d12feea33df
- https://git.kernel.org/stable/c/f1f7122bb2ef056afc6f91ce4c35ab6df1207c8d
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-50285
In the Linux kernel, the following vulnerability has been resolved: mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages The h->*_huge_pages counters are protected by the hugetlb_lock, but alloc_huge_page has a corner case where it can decrement the counter outside of the lock. This could lead to a corrupted value of h->resv_huge_pages, which we have observed on our systems. Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid a potential race.
- https://git.kernel.org/stable/c/112a005d1ded04a4b41b6d01833cc0bda90625cc
- https://git.kernel.org/stable/c/11993652d0b49e27272db0a37aa828d8a3a4b92b
- https://git.kernel.org/stable/c/12df140f0bdfae5dcfc81800970dd7f6f632e00c
- https://git.kernel.org/stable/c/2b35432d324898ec41beb27031d2a1a864a4d40e
- https://git.kernel.org/stable/c/3e50a07b6a5fcd39df1534d3fdaca4292a65efe6
- https://git.kernel.org/stable/c/568e3812b1778b4c0c229649b59977d88f400ece
- https://git.kernel.org/stable/c/629c986e19fe9481227c7cdfd9a105bbc104d245
- https://git.kernel.org/stable/c/c828fab903725279aa9dc6ae3d44bb7e4778f92c
Modified: 2025-12-04
CVE-2022-50291
In the Linux kernel, the following vulnerability has been resolved: kcm: annotate data-races around kcm->rx_psock kcm->rx_psock can be read locklessly in kcm_rfree(). Annotate the read and writes accordingly. We do the same for kcm->rx_wait in the following patch. syzbot reported: BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1: unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313 kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373 __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301 strp_recv+0x6d/0x80 net/strparser/strparser.c:335 tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strp_read_sock net/strparser/strparser.c:358 [inline] do_strp_work net/strparser/strparser.c:406 [inline] strp_work+0xe8/0x180 net/strparser/strparser.c:415 process_one_work+0x3d3/0x720 kernel/workqueue.c:2289 worker_thread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181 skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841 skb_release_all net/core/skbuff.c:852 [inline] __kfree_skb net/core/skbuff.c:868 [inline] kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891 kfree_skb include/linux/skbuff.h:1216 [inline] kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 ____sys_recvmsg+0x16c/0x2e0 ___sys_recvmsg net/socket.c:2743 [inline] do_recvmmsg+0x2f1/0x710 net/socket.c:2837 __sys_recvmmsg net/socket.c:2916 [inline] __do_sys_recvmmsg net/socket.c:2939 [inline] __se_sys_recvmmsg net/socket.c:2932 [inline] __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0xffff88812971ce00 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
- https://git.kernel.org/stable/c/12a0eb340c9a22e0f8c00d2c0c1a60695ead926a
- https://git.kernel.org/stable/c/13dba69e18d04c8eec7596369f2a0596b0260275
- https://git.kernel.org/stable/c/15e4dabda11b0fa31d510a915d1a580f47dfc92e
- https://git.kernel.org/stable/c/1b8a5692ab25db4ef1c2cc8e5d21f7a65dc3d079
- https://git.kernel.org/stable/c/342d918cf9a45df9cf11bbe7162b851adefd178f
- https://git.kernel.org/stable/c/bf46af730e58d340f6f740bc69a07c5f6b85c655
- https://git.kernel.org/stable/c/c325f92d8d9b223d5842609ca067e898e9d34566
- https://git.kernel.org/stable/c/e94395e916b48a5b912a0a04570981b5b091acb0
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-50315
In the Linux kernel, the following vulnerability has been resolved:
ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTS
UBSAN complains about array-index-out-of-bounds:
[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41
[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'
[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu
[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010
[ 1.980718] kernel: Call Trace:
[ 1.980721] kernel:
- https://git.kernel.org/stable/c/1e41e693f458eef2d5728207dbd327cd3b16580a
- https://git.kernel.org/stable/c/303d0f761431d848dd8d7ff9fd9b8c101879cabe
- https://git.kernel.org/stable/c/383b7c50f5445ff8dbbf03080905648d6980c39d
- https://git.kernel.org/stable/c/67a00c299c5c143817c948fbc7de1a2fa1af38fb
- https://git.kernel.org/stable/c/8fbe13de1cc7cef2564be3cbf60400b33eee023b
- https://git.kernel.org/stable/c/d6314d5f68764550c84d732ce901ddd3ac6b415f
- https://git.kernel.org/stable/c/da2ea4a961d9f89ed248734e7032350c260dc3a3
- https://git.kernel.org/stable/c/f70bd4339cb68bc7e206af4c922bc0d249244403
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-50352
In the Linux kernel, the following vulnerability has been resolved: net: hns: fix possible memory leak in hnae_ae_register() Inject fault while probing module, if device_register() fails, but the refcount of kobject is not decreased to 0, the name allocated in dev_set_name() is leaked. Fix this by calling put_device(), so that name can be freed in callback function kobject_cleanup(). unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]
- https://git.kernel.org/stable/c/02dc0db19d944b4a90941db505ecf1aaec714be4
- https://git.kernel.org/stable/c/2974f3b330ef25f5d34a4948d04290c2cd7802cf
- https://git.kernel.org/stable/c/3b78453cca046d3b03853f0d077ad3ad130db886
- https://git.kernel.org/stable/c/7ae1345f6ad715acbcdc9e1ac28153684fd498bb
- https://git.kernel.org/stable/c/91f8f5342bee726ed5692583d58f69e7cc9ae60e
- https://git.kernel.org/stable/c/a3c148955c22fe1d94d7a2096005679c1f22eddf
- https://git.kernel.org/stable/c/dfc0337c6dceb6449403b33ecb141f4a1458a1e9
- https://git.kernel.org/stable/c/ff2f5ec5d009844ec28f171123f9e58750cef4bf
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-50356
In the Linux kernel, the following vulnerability has been resolved:
net: sched: sfb: fix null pointer access issue when sfb_init() fails
When the default qdisc is sfb, if the qdisc of dev_queue fails to be
inited during mqprio_init(), sfb_reset() is invoked to clear resources.
In this case, the q->qdisc is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
sfb_init()
tcf_block_get() --->failed, q->qdisc is NULL
...
qdisc_put()
...
sfb_reset()
qdisc_reset(q->qdisc) --->q->qdisc is NULL
ops = qdisc->ops
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:qdisc_reset+0x2b/0x6f0
Call Trace:
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-50368
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502668/
- https://git.kernel.org/stable/c/21c4679af01f1027cb559330c2e7d410089b2b36
- https://git.kernel.org/stable/c/2e786eb2f9cebb07e317226b60054df510b60c65
- https://git.kernel.org/stable/c/4e5587cddb334f7a5bb1c49ea8bbfc966fafe1b8
- https://git.kernel.org/stable/c/9f035d1fb30648fe70ee01627eb131c56d699b35
- https://git.kernel.org/stable/c/e83b354890a3c1d5256162f87a6cc38c47ae7f20
- https://git.kernel.org/stable/c/f649ed0e1b7a1545f8e27267d3c468b3cb222ece
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-50380
In the Linux kernel, the following vulnerability has been resolved: mm: /proc/pid/smaps_rollup: fix no vma's null-deref Commit 258f669e7e88 ("mm: /proc/pid/smaps_rollup: convert to single value seq_file") introduced a null-deref if there are no vma's in the task in show_smaps_rollup.
- https://git.kernel.org/stable/c/33fc9e26b7cb39f0d4219c875a2451802249c225
- https://git.kernel.org/stable/c/6bb8769326c46db3058780c0640dcc49d8187b24
- https://git.kernel.org/stable/c/97898139ca9b81ba9322a585e07490983c53b55a
- https://git.kernel.org/stable/c/a50ed2d28727ff605d95fb9a53be8ff94e8eaaf4
- https://git.kernel.org/stable/c/c4c84f06285e48f80e9843d0775ad92714ffc35a
- https://git.kernel.org/stable/c/dbe863bce7679c7f5ec0e993d834fe16c5e687b5
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-50387
In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix the issue of CMDQ memory leaks When hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory is not released correctly. Fix it.
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-20
CVE-2022-50427
In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix possible memory leak in snd_ac97_dev_register() If device_register() fails in snd_ac97_dev_register(), it should call put_device() to give up reference, or the name allocated in dev_set_name() is leaked.
- https://git.kernel.org/stable/c/0f8e9a15c8ecf95057061d370a2dddaf1cee4aeb
- https://git.kernel.org/stable/c/4881bda5ea05c8c240fc8afeaa928e2bc43f61fa
- https://git.kernel.org/stable/c/4fdf6f978c6b605ca0d67bf0e982b7a8fc0f4aab
- https://git.kernel.org/stable/c/758dbcc6fbf2286eff02743b093c70a18a407d66
- https://git.kernel.org/stable/c/a602ec9d88f177dba78bc97fb1adecc7a71ff279
- https://git.kernel.org/stable/c/bfce73088682ef0770da951f51156c36a89be490
- https://git.kernel.org/stable/c/c68b2e9ef246117f696e360bbdd2f5736b3a7127
- https://git.kernel.org/stable/c/ee8bf0946f62ef00e5db4b613a9f664ac567259a
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-20
CVE-2022-50431
In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev() dev_set_name() in soundbus_add_one() allocates memory for name, it need be freed when of_device_register() fails, call soundbus_dev_put() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. And other resources are also freed in i2sbus_release_dev(), so it can return 0 directly.
- https://git.kernel.org/stable/c/027fee10e3a400cf6f3237374a1248da1082807b
- https://git.kernel.org/stable/c/4a4c8482e370d697738a78dcd7bf2780832cb712
- https://git.kernel.org/stable/c/5bdea674534153110b90d70b02f2fbaf48b2c0eb
- https://git.kernel.org/stable/c/802532a50acf501fdafe38a84ca2aa886d68af68
- https://git.kernel.org/stable/c/c7524279c8ddc7dbf3463bec70e0289097959944
- https://git.kernel.org/stable/c/ce6fd1c382a38b75557db85a2fe99d285540a03d
- https://git.kernel.org/stable/c/e81d7826b8f40430a1ea1b330e24d9a9eb4512c4
- https://git.kernel.org/stable/c/fd410d24665e4efb3c1796797181265efe553e9c
Modified: 2026-01-20
CVE-2022-50432
In the Linux kernel, the following vulnerability has been resolved:
kernfs: fix use-after-free in __kernfs_remove
Syzkaller managed to trigger concurrent calls to
kernfs_remove_by_name_ns() for the same file resulting in
a KASAN detected use-after-free. The race occurs when the root
node is freed during kernfs_drain().
To prevent this acquire an additional reference for the root
of the tree that is removed before calling __kernfs_remove().
Found by syzkaller with the following reproducer (slab_nomerge is
required):
syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0)
r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0)
close(r0)
pipe2(&(0x7f0000000140)={0xffffffffffffffff,
- https://git.kernel.org/stable/c/028cf780743eea79abffa7206b9dcfc080ad3546
- https://git.kernel.org/stable/c/02eb35131050735332658029082f61515b7dfe38
- https://git.kernel.org/stable/c/4abc99652812a2ddf932f137515d5c5a04723538
- https://git.kernel.org/stable/c/4dfd6a477a1525773469feaf3c514b2c0fef76b5
- https://git.kernel.org/stable/c/6f72a3977ba9d0e5491a5c01315204272e7f9c44
- https://git.kernel.org/stable/c/94d2643df1e70a4c310ebb5e2c493eec33df1a06
- https://git.kernel.org/stable/c/af1b57cc39beca203559576b3046094fc9e5eb32
- https://git.kernel.org/stable/c/c78b0dc6fb7fb389d674e491fd376388cdfb1d53
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-21
CVE-2022-50437
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502670/
- https://git.kernel.org/stable/c/08c7375fa27a8ceee028868e03ffb3a0db919d44
- https://git.kernel.org/stable/c/3c43f3ec731c233eb84b66199ee76dbf3ec6ecae
- https://git.kernel.org/stable/c/4c1294da6aed1f16d47a417dcfe6602833c3c95c
- https://git.kernel.org/stable/c/9efb45b45ff6254bfd1f1997a06725cb3fc998a5
- https://git.kernel.org/stable/c/a9c1a6991a9b5aa6d0f2cbc9b8c3bf6c4d094dfa
- https://git.kernel.org/stable/c/b48949ab451eaf1e2c04c272c8a9a96a2b56546f
- https://git.kernel.org/stable/c/e8f916b84e4b028ecad6c6472eaad543cc7df806
- https://git.kernel.org/stable/c/ed7f1ff87a4afea1bc220d2ff00a7ce8e61f0b53
Modified: 2026-01-21
CVE-2022-50438
In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix memory leak when reading function table When the input parameter idx meets the expected case option in hinic_dbg_get_func_table(), read_data is not released. Fix it.
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-50452
In the Linux kernel, the following vulnerability has been resolved:
net: sched: cake: fix null pointer access issue when cake_init() fails
When the default qdisc is cake, if the qdisc of dev_queue fails to be
inited during mqprio_init(), cake_reset() is invoked to clear
resources. In this case, the tins is NULL, and it will cause gpf issue.
The process is as follows:
qdisc_create_dflt()
cake_init()
q->tins = kvcalloc(...) --->failed, q->tins is NULL
...
qdisc_put()
...
cake_reset()
...
cake_dequeue_one()
b = &q->tins[...] --->q->tins is NULL
The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:cake_dequeue_one+0xc9/0x3c0
Call Trace:
- https://git.kernel.org/stable/c/154f4c06d9dbec1a14e91286c70b6305810302e0
- https://git.kernel.org/stable/c/1dc0a019550fd38ec6cab2d73c90df2bd659c96b
- https://git.kernel.org/stable/c/51f9a8921ceacd7bf0d3f47fa867a64988ba1dcb
- https://git.kernel.org/stable/c/86aa1390898146f1de277bb6d2a8ed7fc7a43f12
- https://git.kernel.org/stable/c/ae48bee2830bf216800e1447baca39541e27a12e
- https://git.kernel.org/stable/c/bc8301ea7e7f1bb9d2ba2fcdf7b5ec2f0792b47e
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-16
CVE-2022-50460
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix xid leak in cifs_flock() If not flock, before return -ENOLCK, should free the xid, otherwise, the xid will be leaked.
Modified: 2026-01-16
CVE-2022-50466
In the Linux kernel, the following vulnerability has been resolved:
fs/binfmt_elf: Fix memory leak in load_elf_binary()
There is a memory leak reported by kmemleak:
unreferenced object 0xffff88817104ef80 (size 224):
comm "xfs_admin", pid 47165, jiffies 4298708825 (age 1333.476s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60 a8 b3 00 81 88 ff ff a8 10 5a 00 81 88 ff ff `.........Z.....
backtrace:
[
Modified: 2026-01-23
CVE-2022-50470
In the Linux kernel, the following vulnerability has been resolved: xhci: Remove device endpoints from bandwidth list when freeing the device Endpoints are normally deleted from the bandwidth list when they are dropped, before the virt device is freed. If xHC host is dying or being removed then the endpoints aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host controller. So check and delete endpoints that are still on the bandwidth list when freeing the virt device. Solves a list_del corruption kernel crash when unbinding xhci-pci, caused by xhci_mem_cleanup() when it later tried to delete already freed endpoints from the bandwidth list. This only affects hosts that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)
- https://git.kernel.org/stable/c/3bf860a41e0f2fcea0ac3aae8f7ef887a7994b70
- https://git.kernel.org/stable/c/5aed5b7c2430ce318a8e62f752f181e66f0d1053
- https://git.kernel.org/stable/c/5e4ce28ad907aa54f13b21d5f1dc490525957b0c
- https://git.kernel.org/stable/c/678d2cc2041cc6ce05030852dce9ad42719abcfc
- https://git.kernel.org/stable/c/8f1cd9633d1f21efc13e8fc75be8f2b6bb85e38c
- https://git.kernel.org/stable/c/c892a81c7424b4f6a660cb9c249d354ccf3afeca
- https://git.kernel.org/stable/c/cebbc8d335d6bcc1316584f779c08f80287c6af8
- https://git.kernel.org/stable/c/f0de39474078adef6ece7a183e34c15ce2c1d8d1
Modified: 2026-01-23
CVE-2022-50471
In the Linux kernel, the following vulnerability has been resolved:
xen/gntdev: Accommodate VMA splitting
Prior to this commit, the gntdev driver code did not handle the
following scenario correctly with paravirtualized (PV) Xen domains:
* User process sets up a gntdev mapping composed of two grant mappings
(i.e., two pages shared by another Xen domain).
* User process munmap()s one of the pages.
* User process munmap()s the remaining page.
* User process exits.
In the scenario above, the user process would cause the kernel to log
the following messages in dmesg for the first munmap(), and the second
munmap() call would result in similar log messages:
BUG: Bad page map in process doublemap.test pte:... pmd:...
page:0000000057c97bff refcount:1 mapcount:-1 \
mapping:0000000000000000 index:0x0 pfn:...
...
page dumped because: bad pte
...
file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0
...
Call Trace:
- https://git.kernel.org/stable/c/3c6a888e352283a14f37b9b433cd598a1a3a7dd0
- https://git.kernel.org/stable/c/4fb4053d90caa9985b87ec0e0c32c66a55bdfa3a
- https://git.kernel.org/stable/c/5c13a4a0291b30191eff9ead8d010e1ca43a4d0c
- https://git.kernel.org/stable/c/7c16d0a4e6a436b4e7c92bead3fab55aaa4c1141
- https://git.kernel.org/stable/c/cdafa219ace013c594e2491158ad1b51f9923dde
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-50482
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clean up si_domain in the init_dmars() error path A splat from kmem_cache_destroy() was seen with a kernel prior to commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") when there was a failure in init_dmars(), because the iommu_domain cache still had objects. While the mempool code is now gone, there still is a leak of the si_domain memory if init_dmars() fails. So clean up si_domain in the init_dmars() error path.
- https://git.kernel.org/stable/c/0365d6af75f9f2696e94a0fef24a2c8464c037c8
- https://git.kernel.org/stable/c/5cecfe151874b835331efe086bbdcaeaf64f6b90
- https://git.kernel.org/stable/c/620bf9f981365c18cc2766c53d92bf8131c63f32
- https://git.kernel.org/stable/c/724483b585a1b1e063d42ac5aa835707ff2ec165
- https://git.kernel.org/stable/c/749bea542b67513e99240dc58bbfc099e842d508
- https://git.kernel.org/stable/c/c4ad3ae4c6be9d8b0701761c839771116bca6ea3
- https://git.kernel.org/stable/c/d74196bb278b8f8af88e16bd595997dfa3d6fdb0
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-03-25
CVE-2022-50491
In the Linux kernel, the following vulnerability has been resolved:
coresight: cti: Fix hang in cti_disable_hw()
cti_enable_hw() and cti_disable_hw() are called from an atomic context
so shouldn't use runtime PM because it can result in a sleep when
communicating with firmware.
Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock
management to the SCMI power domain""), this causes a hang on Juno when
running the Perf Coresight tests or running this command:
perf record -e cs_etm//u -- ls
This was also missed until the revert commit because pm_runtime_put()
was called with the wrong device until commit 692c9a499b28 ("coresight:
cti: Correct the parameter for pm_runtime_put")
With lock and scheduler debugging enabled the following is output:
coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti
BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec
preempt_count: 2, expected: 0
RCU nest depth: 0, expected: 0
INFO: lockdep is turned off.
irq event stamp: 0
hardirqs last enabled at (0): [<0000000000000000>] 0x0
hardirqs last disabled at (0): [
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-03-17
CVE-2022-50531
In the Linux kernel, the following vulnerability has been resolved: tipc: fix an information leak in tipc_topsrv_kern_subscr Use a 8-byte write to initialize sub.usr_handle in tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized when issuing setsockopt(..., SOL_TIPC, ...). This resulted in an infoleak reported by KMSAN when the packet was received: ===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169 instrument_copy_to_user ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/iov_iter.c:169 _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527 copy_to_iter ./include/linux/uio.h:176 simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419 skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527 skb_copy_datagram_msg ./include/linux/skbuff.h:3903 packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469 ____sys_recvmsg+0x2c4/0x810 net/socket.c:? ___sys_recvmsg+0x217/0x840 net/socket.c:2743 __sys_recvmsg net/socket.c:2773 __do_sys_recvmsg net/socket.c:2783 __se_sys_recvmsg net/socket.c:2780 __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 ... Uninit was stored to memory at: tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375 tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084 tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201 __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 __se_sys_setsockopt net/socket.c:2260 __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 Local variable sub created at: tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================
- https://git.kernel.org/stable/c/3d1b83ff7b6575a4e41283203e6b2e25ea700cd7
- https://git.kernel.org/stable/c/567f8de358b61015dcfb8878a1f06c5369a45f54
- https://git.kernel.org/stable/c/777ecaabd614d47c482a5c9031579e66da13989a
- https://git.kernel.org/stable/c/dbc01c0a4e202a7e925dad1d4b7c1d6eb0c81154
- https://git.kernel.org/stable/c/e558e148938442dd49628cd7ef61c360832bef31
- https://git.kernel.org/stable/c/fef70f978bc289642501d88d2a3f5e841bd31a67
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
Modified: 2026-02-05
CVE-2022-50555
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a null-ptr-deref in tipc_topsrv_accept
syzbot found a crash in tipc_topsrv_accept:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
Workqueue: tipc_rcv tipc_topsrv_accept
RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487
Call Trace:
- https://git.kernel.org/stable/c/24b129aed8730e48f47d852d58d76825ab6f407c
- https://git.kernel.org/stable/c/32a3d4660b34ce49ac0162338ebe362098e2f5df
- https://git.kernel.org/stable/c/7a939503fc32bff4ed60800b73ff7fbb4aea2142
- https://git.kernel.org/stable/c/82cb4e4612c633a9ce320e1773114875604a3cce
- https://git.kernel.org/stable/c/ce69bdac2310152bb70845024d5d704c52aabfc3
- https://git.kernel.org/stable/c/cedb41664e27b2cae7e21487f1bee22dcd84037d
Modified: 2024-11-21
CVE-2023-3812
An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system.
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
- https://access.redhat.com/errata/RHSA-2023:6799
- https://access.redhat.com/errata/RHSA-2023:6813
- https://access.redhat.com/errata/RHSA-2023:7370
- https://access.redhat.com/errata/RHSA-2023:7379
- https://access.redhat.com/errata/RHSA-2023:7382
- https://access.redhat.com/errata/RHSA-2023:7389
- https://access.redhat.com/errata/RHSA-2023:7411
- https://access.redhat.com/errata/RHSA-2023:7418
- https://access.redhat.com/errata/RHSA-2023:7548
- https://access.redhat.com/errata/RHSA-2023:7549
- https://access.redhat.com/errata/RHSA-2023:7554
- https://access.redhat.com/errata/RHSA-2024:0340
- https://access.redhat.com/errata/RHSA-2024:0378
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0461
- https://access.redhat.com/errata/RHSA-2024:0554
- https://access.redhat.com/errata/RHSA-2024:0562
- https://access.redhat.com/errata/RHSA-2024:0563
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:0593
- https://access.redhat.com/errata/RHSA-2024:1961
- https://access.redhat.com/errata/RHSA-2024:2006
- https://access.redhat.com/errata/RHSA-2024:2008
- https://access.redhat.com/security/cve/CVE-2023-3812
- https://bugzilla.redhat.com/show_bug.cgi?id=2224048
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0
