ALT-BU-2022-7013-7
Branch p10 update bulletin.
Package anilibria-winmaclinux updated to version 1.2.1-alt3 for branch p10 in task 309762.
Closed bugs
В настройках anilibria-winmaclinux присутствует лишний тумблер
Некорректное выравнивание по правому краю в режиме кастомного тулбара в anilibria-winmaclinux
Свертывание окна в режиме кастомного тулбара в anilibria-winmaclinux
Package kernel-image-un-def updated to version 5.15.77-alt1 for branch p10 in task 309475.
Closed vulnerabilities
BDU:2026-01285
Уязвимость функции kernfs_remove_by_name_ns() модуля fs/kernfs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02372
Уязвимость функции msm_dsi_modeset_init() модуля drivers/gpu/drm/msm/dsi/dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03940
Уязвимость функции skb_append_pagefrags() модуля net/core/skbuff.c поддержки сетевых функций ядра операционной системы 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-05978
Уязвимость функции hinic_init_cmdqs() модуля drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06084
Уязвимость функции hinic_dbg_get_func_table() в модуле drivers/net/ethernet/huawei/hinic/hinic_debugfs.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06092
Уязвимость функции load_elf_binary() в модуле fs/binfmt_elf.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
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-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-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: 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-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-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-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-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-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-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
Package kernel-image-std-def updated to version 5.10.153-alt1 for branch p10 in task 309476.
Closed vulnerabilities
BDU:2026-01285
Уязвимость функции kernfs_remove_by_name_ns() модуля fs/kernfs/dir.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02372
Уязвимость функции msm_dsi_modeset_init() модуля drivers/gpu/drm/msm/dsi/dsi.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы 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-05735
Уязвимость функции alloc_huge_page() модуля mm/hugetlb.c операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05978
Уязвимость функции hinic_init_cmdqs() модуля drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06084
Уязвимость функции hinic_dbg_get_func_table() в модуле drivers/net/ethernet/huawei/hinic/hinic_debugfs.c драйвера сетевых адаптеров Ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06092
Уязвимость функции load_elf_binary() в модуле fs/binfmt_elf.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
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-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: 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-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-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-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-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
