ALT-PU-2022-3094-8
Package kernel-image-std-def updated to version 5.10.154-alt1 for branch p10 in task 309825.
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-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-03975
Уязвимость функции __mdiobus_register() модуля drivers/net/phy/mdio_bus.c драйвера сети физического уровня (PHY) ядра операционной системы 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-06050
Уязвимость функции sc_disable() ядра операционных систем Linux, позволяющая нарушителю вызвать сбой ядра
BDU:2026-06051
Уязвимость функции nf_flow_table_free() ядра операционных систем 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-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-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: 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: 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
