ALT-BU-2023-3011-23
Branch sisyphus update bulletin.
Package libmemcached updated to version 1.1.4-alt1 for branch sisyphus in task 317667.
Closed vulnerabilities
Modified: 2025-06-03
BDU:2023-01570
Уязвимость сервиса кэширования данных memcached библиотеки libmemcached-awesome, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
Modified: 2024-11-21
CVE-2023-27478
libmemcached-awesome is an open source C/C++ client library and tools for the memcached server. `libmemcached` could return data for a previously requested key, if that previous request timed out due to a low `POLL_TIMEOUT`. This issue has been addressed in version 1.1.4. Users are advised to upgrade. There are several ways to workaround or lower the probability of this bug affecting a given deployment. 1: use a reasonably high `POLL_TIMEOUT` setting, like the default. 2: use separate libmemcached connections for unrelated data. 3: do not re-use libmemcached connections in an unknown state.
- https://github.com/awesomized/libmemcached/commit/48dcc61a
- https://github.com/awesomized/libmemcached/releases/tag/1.1.4
- https://github.com/awesomized/libmemcached/security/advisories/GHSA-wwmh-39wj-fx59
- https://github.com/php-memcached-dev/php-memcached/issues/531
- https://github.com/awesomized/libmemcached/commit/48dcc61a
- https://github.com/awesomized/libmemcached/releases/tag/1.1.4
- https://github.com/awesomized/libmemcached/security/advisories/GHSA-wwmh-39wj-fx59
- https://github.com/php-memcached-dev/php-memcached/issues/531
Package libmicrohttpd updated to version 0.9.76-alt1 for branch sisyphus in task 317684.
Closed vulnerabilities
Modified: 2024-11-06
BDU:2024-06864
Уязвимость функции MHD_create_post_processor() реализация веб-сервера HTTP libmicrohttpd, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2023-27371
GNU libmicrohttpd before 0.9.76 allows remote DoS (Denial of Service) due to improper parsing of a multipart/form-data boundary in the postprocessor.c MHD_create_post_processor() method. This allows an attacker to remotely send a malicious HTTP POST packet that includes one or more '\0' bytes in a multipart/form-data boundary field, which - assuming a specific heap layout - will result in an out-of-bounds read and a crash in the find_boundary() function.
- https://git.gnunet.org/libmicrohttpd.git/commit/?id=6d6846e20bfdf4b3eb1b592c97520a532f724238
- https://github.com/0xhebi/CVEs/tree/main/GNU%20Libmicrohttpd
- https://lists.debian.org/debian-lts-announce/2023/03/msg00029.html
- https://lists.gnu.org/archive/html/libmicrohttpd/2023-02/msg00000.html
- https://git.gnunet.org/libmicrohttpd.git/commit/?id=6d6846e20bfdf4b3eb1b592c97520a532f724238
- https://github.com/0xhebi/CVEs/tree/main/GNU%20Libmicrohttpd
- https://lists.debian.org/debian-lts-announce/2023/03/msg00029.html
- https://lists.gnu.org/archive/html/libmicrohttpd/2023-02/msg00000.html
Package alterator-x11 updated to version 1.98.15-alt1 for branch sisyphus in task 317579.
Closed bugs
video_scan -s drivers завершается ошибкой
Package python3-module-poetry-core updated to version 1.5.2-alt1 for branch sisyphus in task 317682.
Closed bugs
poetry-core: new version
Closed vulnerabilities
BDU:2022-01663
Уязвимость функции ftypin компонента mp4read.c аудио декодера Freeware Advanced Audio Decoder 2 (FAAD2), позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2023-11-13
BDU:2022-01666
Уязвимость функции sbr_qmf_analysis_32 компонента sbr_qmf.c аудио декодера Freeware Advanced Audio Decoder 2 (FAAD2), позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2023-11-13
BDU:2022-01667
Уязвимость функции lt_prediction компонента lt_predict.c аудио декодера Freeware Advanced Audio Decoder 2 (FAAD2), позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2022-01813
Уязвимость функции get_sample() компонента output.c аудио декодера Freeware Advanced Audio Decoder 2 (FAAD2), позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2023-11-13
BDU:2022-01814
Уязвимость функции sbr_qmf_synthesis_64 компонента sbr_qmf.c аудио декодера Freeware Advanced Audio Decoder 2 (FAAD2), позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2021-32273
An issue was discovered in faad2 through 2.10.0. A stack-buffer-overflow exists in the function ftypin located in mp4read.c. It allows an attacker to cause Code Execution.
Modified: 2024-11-21
CVE-2021-32274
An issue was discovered in faad2 through 2.10.0. A heap-buffer-overflow exists in the function sbr_qmf_synthesis_64 located in sbr_qmf.c. It allows an attacker to cause code Execution.
- https://github.com/knik0/faad2/issues/60
- https://lists.debian.org/debian-lts-announce/2021/10/msg00020.html
- https://www.debian.org/security/2022/dsa-5109
- https://github.com/knik0/faad2/issues/60
- https://lists.debian.org/debian-lts-announce/2021/10/msg00020.html
- https://www.debian.org/security/2022/dsa-5109
Modified: 2024-11-21
CVE-2021-32276
An issue was discovered in faad2 through 2.10.0. A NULL pointer dereference exists in the function get_sample() located in output.c. It allows an attacker to cause Denial of Service.
- https://github.com/knik0/faad2/issues/58
- https://lists.debian.org/debian-lts-announce/2021/10/msg00020.html
- https://www.debian.org/security/2022/dsa-5109
- https://github.com/knik0/faad2/issues/58
- https://lists.debian.org/debian-lts-announce/2021/10/msg00020.html
- https://www.debian.org/security/2022/dsa-5109
Modified: 2024-11-21
CVE-2021-32277
An issue was discovered in faad2 through 2.10.0. A heap-buffer-overflow exists in the function sbr_qmf_analysis_32 located in sbr_qmf.c. It allows an attacker to cause code Execution.
- https://github.com/knik0/faad2/issues/59
- https://lists.debian.org/debian-lts-announce/2021/10/msg00020.html
- https://www.debian.org/security/2022/dsa-5109
- https://github.com/knik0/faad2/issues/59
- https://lists.debian.org/debian-lts-announce/2021/10/msg00020.html
- https://www.debian.org/security/2022/dsa-5109
Modified: 2024-11-21
CVE-2021-32278
An issue was discovered in faad2 through 2.10.0. A heap-buffer-overflow exists in the function lt_prediction located in lt_predict.c. It allows an attacker to cause code Execution.
- https://github.com/knik0/faad2/issues/62
- https://lists.debian.org/debian-lts-announce/2021/10/msg00020.html
- https://www.debian.org/security/2022/dsa-5109
- https://github.com/knik0/faad2/issues/62
- https://lists.debian.org/debian-lts-announce/2021/10/msg00020.html
- https://www.debian.org/security/2022/dsa-5109
Package xorg-server updated to version 21.1.8-alt1 for branch sisyphus in task 317710.
Closed vulnerabilities
Modified: 2024-09-16
BDU:2023-02146
Уязвимость программного пакета X.Org Server, связанная с использованием памяти после ее освобождения, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-29
CVE-2023-1393
A flaw was found in X.Org Server Overlay Window. A Use-After-Free may lead to local privilege escalation. If a client explicitly destroys the compositor overlay window (aka COW), the Xserver would leave a dangling pointer to that window in the CompScreen structure, which will trigger a use-after-free later.
- https://gitlab.freedesktop.org/xorg/xserver/-/commit/26ef545b3502f61ca722a7a3373507e88ef64110
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BPNQYHUI63DB5FHK6EOI3Z4C6YQZGZKI/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H3EVO3OQV6T4BSABWZ2TU3PY5TJTEQZ2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MEHSYYFGBN3G4RS2HJXKQ5NBMOAZ5F2F/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NOYATGGPMT3COC7ELAJW5TG2PVS3AFR2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PSAAGI5V77FQXIT5PP4URP6BYQVCK5U5/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QHJMSMK7G4GPLMKIGKXIOL2RTKU5VFWE/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SW2NRC3V53PIBXFPFBVWCOM2MDDILWQS/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SWFUDSBSABRHQOX6TIQ5O3SNPFTPFQQP/
- https://security.gentoo.org/glsa/202305-30
- https://www.openwall.com/lists/oss-security/2023/03/29/1
- https://gitlab.freedesktop.org/xorg/xserver/-/commit/26ef545b3502f61ca722a7a3373507e88ef64110
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BPNQYHUI63DB5FHK6EOI3Z4C6YQZGZKI/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/H3EVO3OQV6T4BSABWZ2TU3PY5TJTEQZ2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MEHSYYFGBN3G4RS2HJXKQ5NBMOAZ5F2F/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NOYATGGPMT3COC7ELAJW5TG2PVS3AFR2/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PSAAGI5V77FQXIT5PP4URP6BYQVCK5U5/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QHJMSMK7G4GPLMKIGKXIOL2RTKU5VFWE/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SW2NRC3V53PIBXFPFBVWCOM2MDDILWQS/
- https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SWFUDSBSABRHQOX6TIQ5O3SNPFTPFQQP/
- https://security.gentoo.org/glsa/202305-30
- https://www.openwall.com/lists/oss-security/2023/03/29/1
Package kernel-image-un-def updated to version 6.2.8-alt1 for branch sisyphus in task 317317.
Closed vulnerabilities
Modified: 2024-04-27
BDU:2022-07344
Уязвимость функции find_prog_by_sec_insn() (tools/lib/bpf/libbpf.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-00381
Уязвимость функции rawv6_push_pending_frames() (net/ipv6/raw.c) службы обработки трафика ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-09-30
BDU:2023-00748
Уязвимость видеодрайвера vivid ядра операционной системы Linux, позволяющая локальному нарушителю вызвать отказ в обслуживании
Modified: 2024-10-08
BDU:2023-01125
Уязвимость компонента drivers/tty/vcc.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-02-24
BDU:2023-01215
Уязвимость функции memory_tier_init() (mm/memory-tiers.c) подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2024-09-30
BDU:2023-01282
Уязвимость функции az6027_i2c_xfer() (drivers/media/usb/dvb-usb/az6027.c) драйвера Azurewave DVB-S/S2 USB2.0 AZ6027 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-01726
Уязвимость функции kvm_vcpu_ioctl_x86_get_debugregs() (arch/x86/kvm/x86.c) подсистемы виртуализации KVM ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2025-08-19
BDU:2023-02162
Уязвимость функции nested_vmx_check_guest_state() модуля arch/x86/kvm/vmx/nested.c подсистемы виртуализации (KVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании гостевой операционной системы.
Modified: 2025-01-29
BDU:2023-02166
Уязвимость функции xen_9pfs_front_remove() в модуле net/9p/trans_xen.c гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2023-10-20
BDU:2023-02522
Уязвимость функции io_cqring_event_overflow() в модуле uring/msg_ring.c ядра операционной системы Linux, позволяющая нарушителю повысить привилегии или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02528
Уязвимость драйвере SCSI ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации
Modified: 2024-04-27
BDU:2023-02995
Уязвимость функции ntfs_set_ea() в модуле fs/ntfs3/xattr.c драйвера файловой системы ntfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03170
Уязвимость функции fbcon_set_font() в модуле drivers/video/fbdev/core/fbcon.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-09-30
BDU:2023-03641
Уязвимость функции ishtp_cl_get_dma_send_buf() драйвера Integrated Sensor Hub (ISH) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2023-07-19
BDU:2023-03644
Уязвимость функции brcm_nvram_parse() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-03782
Уязвимость функции vcs_read() в модуле drivers/tty/vt/vc_screen.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2024-04-27
BDU:2023-04647
Уязвимость функции parse_usdt_arg() в модуле tools/lib/bpf/usdt.c компоненты BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-05389
Уязвимость функции unix_stream_sendpage() в модуле net/unix/af_unix.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации или повысить свои привилегии
Modified: 2025-02-27
BDU:2023-06997
Уязвимость функции ms_lib_process_bootblock() в модуле drivers/usb/storage/ene_ub6250.c драйвера ene_usb6250 кард-ридера ENE SD/MS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-08-19
BDU:2023-06998
Уязвимость функции fill_kobj_path() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.
Modified: 2025-08-19
BDU:2024-01930
Уязвимость компонента uvcvideo ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06055
Уязвимость функции sync_print_obj() драйвера dma-buf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06056
Уязвимость функции register_winch_irq() драйвера подсистемы User-Mode Linux (UML) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-04-30
BDU:2024-06057
Уязвимость функции may_update_sockmap() подсистемы BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации
Modified: 2025-05-06
BDU:2024-06066
Уязвимость функции vm_area_alloc_pages() менеджера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06082
Уязвимость структуры davinci_mmcsd_driver драйвера MMC/SD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06083
Уязвимость функции media_pipeline_explore_next_link() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-06084
Уязвимость функции kdb_read() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-08-19
BDU:2024-06088
Уязвимость функции raid5d() драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-06089
Уязвимость функции savagefb_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2024-07484
Уязвимость функции criu_restore_memory_of_gpu() драйвера amdkfd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-29
BDU:2024-07534
Уязвимость компонента block_dirty_buffer файловой системы NILFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-10-18
BDU:2024-07630
Уязвимость компонента fastrpc ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-05-06
BDU:2024-08072
Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-03-21
BDU:2024-08078
Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-08087
Уязвимость функции amdgpu_ring_init() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2024-11669
Уязвимость функции btree_iter компонента bcache ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01656
Уязвимость компонента sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01767
Уязвимость компонентов smb/client ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-05-06
BDU:2025-01922
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-02999
Уязвимость функции add_adev() модуля drivers/net/ethernet/microsoft/mana/mana_en.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-01-20
BDU:2025-03313
Уязвимость компонентов drm/rockchip ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-29
BDU:2025-03321
Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-06-09
BDU:2025-03617
Уязвимость функции unix_gc() модуля net/unix/garbage.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2026-02-17
BDU:2025-06318
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2025-06335
Уязвимость функции __thermal_cooling_device_register() и thermal_cooling_device_destroy_sysfs() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-07001
Уязвимость функции ModeSupportAndSystemConfiguration() драйвера drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации
Modified: 2025-10-24
BDU:2025-07935
Уязвимость ядра операционной системы Linux, связанная с ошибками управления состоянием, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2025-10569
Уязвимость функции hub_port_init() модуля drivers/usb/core/hub.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03882
Уязвимость функции lpuart_set_termios() модуля drivers/tty/serial/fsl_lpuart.c драйвера консоли TTY на последовательном порте ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03973
Уязвимость функции __mptcp_close_ssk() модуля net/mptcp/protocol.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03974
Уязвимость функций __mptcp_close_ssk() и mptcp_worker() модуля net/mptcp/protocol.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05865
Уязвимость ядра операционной системы Linux, связанная с разыменованием нулевого указателя, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-21
CVE-2022-3533
A vulnerability was found in Linux Kernel. It has been rated as problematic. This issue affects the function parse_usdt_arg of the file tools/lib/bpf/usdt.c of the component BPF. The manipulation of the argument reg_name leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211031.
Modified: 2025-11-03
CVE-2022-3606
A vulnerability was found in Linux Kernel. It has been classified as problematic. This affects the function find_prog_by_sec_insn of the file tools/lib/bpf/libbpf.c of the component BPF. The manipulation leads to null pointer dereference. It is recommended to apply a patch to fix this issue. The identifier VDB-211749 was assigned to this vulnerability.
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2
- https://vuldb.com/?id.211749
- https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2
- https://lists.debian.org/debian-lts-announce/2025/04/msg00033.html
- https://vuldb.com/?id.211749
Modified: 2024-11-21
CVE-2022-48502
An issue was discovered in the Linux kernel before 6.2. The ntfs3 subsystem does not properly check for correctness during disk reads, leading to an out-of-bounds read in ntfs_set_ea in fs/ntfs3/xattr.c.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b
- https://security.netapp.com/advisory/ntap-20230703-0004/
- https://syzkaller.appspot.com/bug?extid=8778f030156c6cd16d72
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b
- https://security.netapp.com/advisory/ntap-20230703-0004/
- https://syzkaller.appspot.com/bug?extid=8778f030156c6cd16d72
Modified: 2024-09-06
CVE-2022-48872
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free race condition for maps It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted. Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted. Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall
- https://git.kernel.org/stable/c/079c78c68714f7d8d58e66c477b0243b31806907
- https://git.kernel.org/stable/c/556dfdb226ce1e5231d8836159b23f8bb0395bf4
- https://git.kernel.org/stable/c/61a0890cb95afec5c8a2f4a879de2b6220984ef1
- https://git.kernel.org/stable/c/96b328d119eca7563c1edcc4e1039a62e6370ecb
- https://git.kernel.org/stable/c/b171d0d2cf1b8387c72c8d325c5d5746fa271e39
Modified: 2025-03-31
CVE-2023-0394
A NULL pointer dereference flaw was found in rawv6_push_pending_frames in net/ipv6/raw.c in the network subcomponent in the Linux kernel. This flaw causes the system to crash.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230302-0005/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17
- https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230302-0005/
Modified: 2025-03-25
CVE-2023-0615
A memory leak flaw and potential divide by zero and Integer overflow was found in the Linux kernel V4L2 and vivid test code functionality. This issue occurs when a user triggers ioctls, such as VIDIOC_S_DV_TIMINGS ioctl. This could allow a local user to crash the system if vivid test code enabled.
Modified: 2025-02-25
CVE-2023-1513
A flaw was found in KVM. When calling the KVM_GET_DEBUGREGS ioctl, on 32-bit systems, there might be some uninitialized portions of the kvm_debugregs structure that could be copied to userspace, causing an information leak.
- https://bugzilla.redhat.com/show_bug.cgi?id=2179892
- https://github.com/torvalds/linux/commit/2c10b61421a28e95a46ab489fd56c0f442ff6952
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/kvm/20230214103304.3689213-1-gregkh%40linuxfoundation.org/
- https://bugzilla.redhat.com/show_bug.cgi?id=2179892
- https://github.com/torvalds/linux/commit/2c10b61421a28e95a46ab489fd56c0f442ff6952
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://lore.kernel.org/kvm/20230214103304.3689213-1-gregkh%40linuxfoundation.org/
Modified: 2025-03-18
CVE-2023-1859
A use-after-free flaw was found in xen_9pfs_front_removet in net/9p/trans_xen.c in Xen transport for 9pfs in the Linux Kernel. This flaw could allow a local attacker to crash the system due to a race problem, possibly leading to a kernel information leak.
Modified: 2025-03-19
CVE-2023-2162
A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information.
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.spinics.net/lists/linux-scsi/msg181542.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://www.spinics.net/lists/linux-scsi/msg181542.html
Modified: 2025-03-19
CVE-2023-23005
In the Linux kernel before 6.2, mm/memory-tiers.c misinterprets the alloc_memory_type return value (expects it to be NULL in the error case, whereas it is actually an error pointer). NOTE: this is disputed by third parties because there are no realistic cases in which a user can cause the alloc_memory_type error case to be reached.
- https://bugzilla.suse.com/show_bug.cgi?id=1208844#c2
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
- https://github.com/torvalds/linux/commit/4a625ceee8a0ab0273534cb6b432ce6b331db5ee
- https://bugzilla.suse.com/show_bug.cgi?id=1208844#c2
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2
- https://github.com/torvalds/linux/commit/4a625ceee8a0ab0273534cb6b432ce6b331db5ee
Modified: 2025-03-20
CVE-2023-23039
An issue was discovered in the Linux kernel through 6.2.0-rc2. drivers/tty/vcc.c has a race condition and resultant use-after-free if a physically proximate attacker removes a VCC device while calling open(), aka a race condition between vcc_open() and vcc_remove().
Modified: 2025-03-06
CVE-2023-2430
A vulnerability was found due to missing lock for IOPOLL flaw in io_cqring_event_overflow() in io_uring.c in Linux Kernel. This flaw allows a local attacker with user privilege to trigger a Denial of Service threat.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8
- https://www.debian.org/security/2023/dsa-5492
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8
- https://www.debian.org/security/2023/dsa-5492
Modified: 2025-03-19
CVE-2023-28328
A NULL pointer dereference flaw was found in the az6027 driver in drivers/media/usb/dev-usb/az6027.c in the Linux Kernel. The message from user space is not checked properly before transferring into the device. This flaw allows a local user to crash the system or potentially cause a denial of service.
- https://bugzilla.redhat.com/show_bug.cgi?id=2177389
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://bugzilla.redhat.com/show_bug.cgi?id=2177389
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
Modified: 2025-03-19
CVE-2023-30456
An issue was discovered in arch/x86/kvm/vmx/nested.c in the Linux kernel before 6.2.8. nVMX on x86_64 lacks consistency checks for CR0 and CR4.
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.8
- https://github.com/torvalds/linux/commit/112e66017bff7f2837030f34c2bc19501e9212d5
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230511-0007/
- http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.8
- https://github.com/torvalds/linux/commit/112e66017bff7f2837030f34c2bc19501e9212d5
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230511-0007/
Modified: 2025-03-11
CVE-2023-3161
A flaw was found in the Framebuffer Console (fbcon) in the Linux Kernel. When providing font->width and font->height greater than 32 to fbcon_set_font, since there are no checks in place, a shift-out-of-bounds occurs leading to undefined behavior and possible denial of service.
Modified: 2025-03-10
CVE-2023-3358
A null pointer dereference was found in the Linux kernel's Integrated Sensor Hub (ISH) driver. This issue could allow a local user to crash the system.
Modified: 2025-03-07
CVE-2023-3359
An issue was discovered in the Linux kernel brcm_nvram_parse in drivers/nvmem/brcm_nvram.c. Lacks for the check of the return value of kzalloc() can cause the NULL Pointer Dereference.
Modified: 2024-11-21
CVE-2023-3567
A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This issue may allow an attacker with local user access to cause a system crash or leak internal kernel information.
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0431
- https://access.redhat.com/errata/RHSA-2024:0432
- https://access.redhat.com/errata/RHSA-2024:0439
- https://access.redhat.com/errata/RHSA-2024:0448
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-3567
- https://bugzilla.redhat.com/show_bug.cgi?id=2221463
- https://www.spinics.net/lists/stable-commits/msg285184.html
- http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://access.redhat.com/errata/RHSA-2024:0412
- https://access.redhat.com/errata/RHSA-2024:0431
- https://access.redhat.com/errata/RHSA-2024:0432
- https://access.redhat.com/errata/RHSA-2024:0439
- https://access.redhat.com/errata/RHSA-2024:0448
- https://access.redhat.com/errata/RHSA-2024:0575
- https://access.redhat.com/errata/RHSA-2024:2394
- https://access.redhat.com/errata/RHSA-2024:2950
- https://access.redhat.com/errata/RHSA-2024:3138
- https://access.redhat.com/security/cve/CVE-2023-3567
- https://bugzilla.redhat.com/show_bug.cgi?id=2221463
- https://www.spinics.net/lists/stable-commits/msg285184.html
Modified: 2024-11-21
CVE-2023-45862
An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce33e64c1788912976b61314b56935abd4bc97ef
- https://security.netapp.com/advisory/ntap-20231116-0004/
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.5
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce33e64c1788912976b61314b56935abd4bc97ef
- https://security.netapp.com/advisory/ntap-20231116-0004/
Modified: 2024-11-21
CVE-2023-45863
An issue was discovered in lib/kobject.c in the Linux kernel before 6.2.3. With root access, an attacker can trigger a race condition that results in a fill_kobj_path out-of-bounds write.
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb2a01caa813d3a1845d378bbe4169ef280d394
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
- https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.3
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb2a01caa813d3a1845d378bbe4169ef280d394
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html
Modified: 2025-02-13
CVE-2023-4622
A use-after-free vulnerability in the Linux kernel's af_unix component can be exploited to achieve local privilege escalation. The unix_stream_sendpage() function tries to add data to the last skb in the peer's recv queue without locking the queue. Thus there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free. We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c.
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=790c2f9d15b594350ae9bca7b236f2b1859de02c
- https://kernel.dance/790c2f9d15b594350ae9bca7b236f2b1859de02c
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
- http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html
- https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y&id=790c2f9d15b594350ae9bca7b236f2b1859de02c
- https://kernel.dance/790c2f9d15b594350ae9bca7b236f2b1859de02c
- https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://www.debian.org/security/2023/dsa-5492
Modified: 2024-12-11
CVE-2023-52565
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix OOB read If the index provided by the user is bigger than the mask size, we might do an out of bound read.
- https://git.kernel.org/stable/c/09635bf4cdd4adf2160198a6041bcc7ca46c0558
- https://git.kernel.org/stable/c/41ebaa5e0eebea4c3bac96b72f9f8ae0d77c0bdb
- https://git.kernel.org/stable/c/8bcf70d787f7d53a3b85ad394f926cfef3eed023
- https://git.kernel.org/stable/c/09635bf4cdd4adf2160198a6041bcc7ca46c0558
- https://git.kernel.org/stable/c/41ebaa5e0eebea4c3bac96b72f9f8ae0d77c0bdb
- https://git.kernel.org/stable/c/8bcf70d787f7d53a3b85ad394f926cfef3eed023
Modified: 2024-11-21
CVE-2023-52886
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()
Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors():
BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883
Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011
CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
- https://git.kernel.org/stable/c/7fe9d87996062f5eb0ca476ad0257f79bf43aaf5
- https://git.kernel.org/stable/c/8186596a663506b1124bede9fde6f243ef9f37ee
- https://git.kernel.org/stable/c/9d241c5d9a9b7ad95c90c6520272fe404d5ac88f
- https://git.kernel.org/stable/c/b4a074b1fb222164ed7d5c0b8c922dc4a0840848
- https://git.kernel.org/stable/c/b9fbfb349eacc0820f91c797d7f0a3ac7a4935b5
- https://git.kernel.org/stable/c/ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b
- https://git.kernel.org/stable/c/7fe9d87996062f5eb0ca476ad0257f79bf43aaf5
- https://git.kernel.org/stable/c/8186596a663506b1124bede9fde6f243ef9f37ee
- https://git.kernel.org/stable/c/9d241c5d9a9b7ad95c90c6520272fe404d5ac88f
- https://git.kernel.org/stable/c/b4a074b1fb222164ed7d5c0b8c922dc4a0840848
- https://git.kernel.org/stable/c/b9fbfb349eacc0820f91c797d7f0a3ac7a4935b5
- https://git.kernel.org/stable/c/ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b
Modified: 2025-04-01
CVE-2023-52999
In the Linux kernel, the following vulnerability has been resolved:
net: fix UaF in netns ops registration error path
If net_assign_generic() fails, the current error path in ops_init() tries
to clear the gen pointer slot. Anyway, in such error path, the gen pointer
itself has not been modified yet, and the existing and accessed one is
smaller than the accessed index, causing an out-of-bounds error:
BUG: KASAN: slab-out-of-bounds in ops_init+0x2de/0x320
Write of size 8 at addr ffff888109124978 by task modprobe/1018
CPU: 2 PID: 1018 Comm: modprobe Not tainted 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/12075708f2e77ee6a9f8bb2cf512c38be3099794
- https://git.kernel.org/stable/c/66689a72ba73575e76d4f6a8748d3fa2690ec1c4
- https://git.kernel.org/stable/c/71ab9c3e2253619136c31c89dbb2c69305cc89b1
- https://git.kernel.org/stable/c/ad0dfe9bcf0d78e699c7efb64c90ed062dc48bea
- https://git.kernel.org/stable/c/d4c008f3b7f7d4ffd311eb2dae5e75b3cbddacd0
- https://git.kernel.org/stable/c/ddd49cbbd4c1ceb38032018b589b44208e54f55e
Modified: 2025-10-30
CVE-2023-53012
In the Linux kernel, the following vulnerability has been resolved: thermal: core: call put_device() only after device_register() fails put_device() shouldn't be called before a prior call to device_register(). __thermal_cooling_device_register() doesn't follow that properly and needs fixing. Also thermal_cooling_device_destroy_sysfs() is getting called unnecessarily on few error paths. Fix all this by placing the calls at the right place. Based on initial work done by Caleb Connolly.
Modified: 2025-11-12
CVE-2023-53072
In the Linux kernel, the following vulnerability has been resolved:
mptcp: use the workqueue to destroy unaccepted sockets
Christoph reported a UaF at token lookup time after having
refactored the passive socket initialization part:
BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260
Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198
CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
Modified: 2025-11-12
CVE-2023-53088
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix UaF in listener shutdown
As reported by Christoph after having refactored the passive
socket initialization, the mptcp listener shutdown path is prone
to an UaF issue.
BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x73/0xe0
Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266
CPU: 1 PID: 1266 Comm: syz-executor731 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
Modified: 2025-11-12
CVE-2023-53093
In the Linux kernel, the following vulnerability has been resolved: tracing: Do not let histogram values have some modifiers Histogram values can not be strings, stacktraces, graphs, symbols, syscalls, or grouped in buckets or log. Give an error if a value is set to do so. Note, the histogram code was not prepared to handle these modifiers for histograms and caused a bug. Mark Rutland reported: # echo 'p:copy_to_user __arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copy_to_user/trigger # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist [ 143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 143.695190] Mem abort info: [ 143.695362] ESR = 0x0000000096000004 [ 143.695604] EC = 0x25: DABT (current EL), IL = 32 bits [ 143.695889] SET = 0, FnV = 0 [ 143.696077] EA = 0, S1PTW = 0 [ 143.696302] FSC = 0x04: level 0 translation fault [ 143.702381] Data abort info: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000 [ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 143.704714] Modules linked in: [ 143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3 [ 143.706138] Hardware name: linux,dummy-virt (DT) [ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 143.707120] pc : hist_field_name.part.0+0x14/0x140 [ 143.707504] lr : hist_field_name.part.0+0x104/0x140 [ 143.707774] sp : ffff800008333a30 [ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0 [ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800 [ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001 [ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000 [ 143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c [ 143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c [ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d [ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000 [ 143.711746] Call trace: [ 143.712115] hist_field_name.part.0+0x14/0x140 [ 143.712642] hist_field_name.part.0+0x104/0x140 [ 143.712925] hist_field_print+0x28/0x140 [ 143.713125] event_hist_trigger_print+0x174/0x4d0 [ 143.713348] hist_show+0xf8/0x980 [ 143.713521] seq_read_iter+0x1bc/0x4b0 [ 143.713711] seq_read+0x8c/0xc4 [ 143.713876] vfs_read+0xc8/0x2a4 [ 143.714043] ksys_read+0x70/0xfc [ 143.714218] __arm64_sys_read+0x24/0x30 [ 143.714400] invoke_syscall+0x50/0x120 [ 143.714587] el0_svc_common.constprop.0+0x4c/0x100 [ 143.714807] do_el0_svc+0x44/0xd0 [ 143.714970] el0_svc+0x2c/0x84 [ 143.715134] el0t_64_sync_handler+0xbc/0x140 [ 143.715334] el0t_64_sync+0x190/0x194 [ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000) [ 143.716510] ---[ end trace 0000000000000000 ]--- Segmentation fault
Modified: 2025-11-12
CVE-2023-53094
In the Linux kernel, the following vulnerability has been resolved:
tty: serial: fsl_lpuart: fix race on RX DMA shutdown
From time to time DMA completion can come in the middle of DMA shutdown:
- https://git.kernel.org/stable/c/19a98d56dfedafb25652bdb9cd48a4e73ceba702
- https://git.kernel.org/stable/c/1be6f2b15f902c02e055ae0b419ca789200473c9
- https://git.kernel.org/stable/c/2a36b444cace9580380467fd1183bb5e85bcc80a
- https://git.kernel.org/stable/c/90530e7214c8a04dcdde57502d93fa96af288c38
- https://git.kernel.org/stable/c/954fc9931f0aabf272b5674cf468affdd88d3a36
Modified: 2025-05-07
CVE-2024-26676
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.
syzbot reported a warning [0] in __unix_gc() with a repro, which
creates a socketpair and sends one socket's fd to itself using the
peer.
socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\360", iov_len=1}],
msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_RIGHTS, cmsg_data=[3]}],
msg_controllen=24, msg_flags=0}, MSG_OOB|MSG_PROBE|MSG_DONTWAIT|MSG_ZEROCOPY) = 1
This forms a self-cyclic reference that GC should finally untangle
but does not due to lack of MSG_OOB handling, resulting in memory
leak.
Recently, commit 11498715f266 ("af_unix: Remove io_uring code for
GC.") removed io_uring's dead code in GC and revealed the problem.
The code was executed at the final stage of GC and unconditionally
moved all GC candidates from gc_candidates to gc_inflight_list.
That papered over the reported problem by always making the following
WARN_ON_ONCE(!list_empty(&gc_candidates)) false.
The problem has been there since commit 2aab4b969002 ("af_unix: fix
struct pid leaks in OOB support") added full scm support for MSG_OOB
while fixing another bug.
To fix this problem, we must call kfree_skb() for unix_sk(sk)->oob_skb
if the socket still exists in gc_candidates after purging collected skb.
Then, we need to set NULL to oob_skb before calling kfree_skb() because
it calls last fput() and triggers unix_release_sock(), where we call
duplicate kfree_skb(u->oob_skb) if not NULL.
Note that the leaked socket remained being linked to a global list, so
kmemleak also could not detect it. We need to check /proc/net/protocol
to notice the unfreed socket.
[0]:
WARNING: CPU: 0 PID: 2863 at net/unix/garbage.c:345 __unix_gc+0xc74/0xe80 net/unix/garbage.c:345
Modules linked in:
CPU: 0 PID: 2863 Comm: kworker/u4:11 Not tainted 6.8.0-rc1-syzkaller-00583-g1701940b1a02 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: events_unbound __unix_gc
RIP: 0010:__unix_gc+0xc74/0xe80 net/unix/garbage.c:345
Code: 8b 5c 24 50 e9 86 f8 ff ff e8 f8 e4 22 f8 31 d2 48 c7 c6 30 6a 69 89 4c 89 ef e8 97 ef ff ff e9 80 f9 ff ff e8 dd e4 22 f8 90 <0f> 0b 90 e9 7b fd ff ff 48 89 df e8 5c e7 7c f8 e9 d3 f8 ff ff e8
RSP: 0018:ffffc9000b03fba0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffc9000b03fc10 RCX: ffffffff816c493e
RDX: ffff88802c02d940 RSI: ffffffff896982f3 RDI: ffffc9000b03fb30
RBP: ffffc9000b03fce0 R08: 0000000000000001 R09: fffff52001607f66
R10: 0000000000000003 R11: 0000000000000002 R12: dffffc0000000000
R13: ffffc9000b03fc10 R14: ffffc9000b03fc10 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005559c8677a60 CR3: 000000000d57a000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d
- https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668
- https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140
- https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276
- https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b
- https://git.kernel.org/stable/c/1279f9d9dec2d7462823a18c29ad61359e0a007d
- https://git.kernel.org/stable/c/4fe505c63aa3273135a57597fda761e9aecc7668
- https://git.kernel.org/stable/c/82ae47c5c3a6b27fdc0f9e83c1499cb439c56140
- https://git.kernel.org/stable/c/b74aa9ce13d02b7fd37c5325b99854f91b9b4276
- https://git.kernel.org/stable/c/e0e09186d8821ad59806115d347ea32efa43ca4b
Modified: 2024-11-21
CVE-2024-38662
In the Linux kernel, the following vulnerability has been resolved: bpf: Allow delete from sockmap/sockhash only if update is allowed We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash. We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map. From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types.
- https://git.kernel.org/stable/c/000a65bf1dc04fb2b65e2abf116f0bc0fc2ee7b1
- https://git.kernel.org/stable/c/11e8ecc5b86037fec43d07b1c162e233e131b1d9
- https://git.kernel.org/stable/c/29467edc23818dc5a33042ffb4920b49b090e63d
- https://git.kernel.org/stable/c/6693b172f008846811f48a099f33effc26068e1e
- https://git.kernel.org/stable/c/98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d
- https://git.kernel.org/stable/c/b81e1c5a3c70398cf76631ede63a03616ed1ba3c
- https://git.kernel.org/stable/c/000a65bf1dc04fb2b65e2abf116f0bc0fc2ee7b1
- https://git.kernel.org/stable/c/11e8ecc5b86037fec43d07b1c162e233e131b1d9
- https://git.kernel.org/stable/c/29467edc23818dc5a33042ffb4920b49b090e63d
- https://git.kernel.org/stable/c/6693b172f008846811f48a099f33effc26068e1e
- https://git.kernel.org/stable/c/98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d
- https://git.kernel.org/stable/c/b81e1c5a3c70398cf76631ede63a03616ed1ba3c
Modified: 2025-11-04
CVE-2024-38780
In the Linux kernel, the following vulnerability has been resolved: dma-buf/sw-sync: don't enable IRQ from sync_print_obj() Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq().
- https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed
- https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a
- https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a
- https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e
- https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878
- https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef
- https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8
- https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39
- https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed
- https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a
- https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a
- https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e
- https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878
- https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef
- https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8
- https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-04
CVE-2024-39292
In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails.
- https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4
- https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2
- https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14
- https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0
- https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33
- https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a73b87f1
- https://git.kernel.org/stable/c/a0fbbd36c156b9f7b2276871d499c9943dfe5101
- https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0
- https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4
- https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2
- https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14
- https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0
- https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33
- https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a73b87f1
- https://git.kernel.org/stable/c/a0fbbd36c156b9f7b2276871d499c9943dfe5101
- https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Modified: 2025-11-03
CVE-2024-39474
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") includes support for __GFP_NOFAIL, but it presents a conflict with commit dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A possible scenario is as follows: process-a __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) __vmalloc_area_node() vm_area_alloc_pages() --> oom-killer send SIGKILL to process-a if (fatal_signal_pending(current)) break; --> return NULL; To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() if __GFP_NOFAIL set. This issue occurred during OPLUS KASAN TEST. Below is part of the log -> oom-killer sends signal to process [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198 [65731.259685] [T32454] Call trace: [65731.259698] [T32454] dump_backtrace+0xf4/0x118 [65731.259734] [T32454] show_stack+0x18/0x24 [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c [65731.259781] [T32454] dump_stack+0x18/0x38 [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump] [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc [65731.260047] [T32454] notify_die+0x114/0x198 [65731.260073] [T32454] die+0xf4/0x5b4 [65731.260098] [T32454] die_kernel_fault+0x80/0x98 [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8 [65731.260146] [T32454] do_bad_area+0x68/0x148 [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 [65731.260204] [T32454] el1_abort+0x3c/0x5c [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 [65731.260248] [T32454] el1h_64_sync+0x68/0x6c [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 --> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); kernel panic by NULL pointer dereference. erofs assume kvmalloc with __GFP_NOFAIL never return NULL. [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 [65731.260339] [T32454] read_pages+0x170/0xadc [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 [65731.260437] [T32454] __do_fault+0xd0/0x33c [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0 [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 [65731.260509] [T32454] el0_da+0x44/0x94 [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 [65731.260553] [T32454] el0t_64_sync+0x198/0x19c
- https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91
- https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4
- https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc
- https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da
- https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91
- https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4
- https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc
- https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2024-11-21
CVE-2024-39475
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Handle err return when savagefb_check_var failed The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
- https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b
- https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089
- https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95
- https://git.kernel.org/stable/c/6ad959b6703e2c4c5d7af03b4cfd5ff608036339
- https://git.kernel.org/stable/c/86435f39c18967cdd937d7a49ba539cdea7fb547
- https://git.kernel.org/stable/c/b8385ff814ca4cb7e63789841e6ec2a14c73e1e8
- https://git.kernel.org/stable/c/be754cbd77eaf2932408a4e18532e4945274a5c7
- https://git.kernel.org/stable/c/edaa57480b876e8203b51df7c3d14a51ea6b09e3
- https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b
- https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089
- https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95
- https://git.kernel.org/stable/c/6ad959b6703e2c4c5d7af03b4cfd5ff608036339
- https://git.kernel.org/stable/c/86435f39c18967cdd937d7a49ba539cdea7fb547
- https://git.kernel.org/stable/c/b8385ff814ca4cb7e63789841e6ec2a14c73e1e8
- https://git.kernel.org/stable/c/be754cbd77eaf2932408a4e18532e4945274a5c7
- https://git.kernel.org/stable/c/edaa57480b876e8203b51df7c3d14a51ea6b09e3
Modified: 2024-11-21
CVE-2024-39476
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well.
- https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a
- https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa
- https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
- https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4
- https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787
- https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347
- https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447
- https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7
- https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a
- https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa
- https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
- https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4
- https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787
- https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347
- https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447
- https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7
Modified: 2024-11-21
CVE-2024-39480
In the Linux kernel, the following vulnerability has been resolved: kdb: Fix buffer overflow during tab-complete Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around.
- https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5
- https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7
- https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96
- https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a
- https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454
- https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33
- https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7
- https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992
- https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5
- https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7
- https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96
- https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a
- https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454
- https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33
- https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7
- https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992
Modified: 2024-11-21
CVE-2024-39481
In the Linux kernel, the following vulnerability has been resolved: media: mc: Fix graph walk in media_pipeline_start The graph walk tries to follow all links, even if they are not between pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link. Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK links.
- https://git.kernel.org/stable/c/788fd0f11e45ae8d3a8ebbd3452a6e83f92db376
- https://git.kernel.org/stable/c/8a9d420149c477e7c97fbd6453704e4612bdd3fa
- https://git.kernel.org/stable/c/bee9440bc0b6b3b7432f7bfde28656262a3484a2
- https://git.kernel.org/stable/c/e80d9db99b7b6c697d8d952dfd25c3425cf61499
- https://git.kernel.org/stable/c/788fd0f11e45ae8d3a8ebbd3452a6e83f92db376
- https://git.kernel.org/stable/c/8a9d420149c477e7c97fbd6453704e4612bdd3fa
- https://git.kernel.org/stable/c/bee9440bc0b6b3b7432f7bfde28656262a3484a2
- https://git.kernel.org/stable/c/e80d9db99b7b6c697d8d952dfd25c3425cf61499
Modified: 2024-11-21
CVE-2024-39482
In the Linux kernel, the following vulnerability has been resolved: bcache: fix variable length array abuse in btree_iter btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array.
- https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671
- https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b
- https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31
- https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023
- https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148
- https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02
- https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671
- https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b
- https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31
- https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023
- https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148
- https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02
Modified: 2025-11-03
CVE-2024-39484
In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text)
- https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584
- https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3
- https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e
- https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4
- https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb
- https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1
- https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584
- https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3
- https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e
- https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4
- https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb
- https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-41011
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space.
- https://git.kernel.org/stable/c/009c4d78bcf07c4ac2e3dd9f275b4eaa72b4f884
- https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
- https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5
- https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28
- https://git.kernel.org/stable/c/8ad4838040e5515939c071a0f511ce2661a0889d
- https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7
- https://git.kernel.org/stable/c/f7276cdc1912325b64c33fcb1361952c06e55f63
- https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724
- https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5
- https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28
- https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
Modified: 2025-11-03
CVE-2024-42069
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix possible double free in error handling path When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function adev_release calls kfree(madev). We shouldn't call kfree(madev) again in the error handling path. Set 'madev' to NULL.
- https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc
- https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a
- https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4
- https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc
- https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a
- https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4
- https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html
Modified: 2025-11-03
CVE-2024-43897
In the Linux kernel, the following vulnerability has been resolved: net: drop bad gso csum_start and offset in virtio_net_hdr Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets. The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation. Syzkaller demonstrated to reach this warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) By injecting a TSO packet: WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h:4864 [inline] xmit_one net/core/dev.c:3595 [inline] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261 packet_snd net/packet/af_packet.c:3073 [inline] The geometry of the bad input packet at tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0) Mitigate with stricter input validation. csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software. csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload. GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no need to test for ip_summed == CHECKSUM_PARTIAL first. This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests.
- https://git.kernel.org/stable/c/2edbb3e8838c672cd7e247e47989df9d03fc6668
- https://git.kernel.org/stable/c/413e785a89f8bde0d4156a54b8ac2fa003c06756
- https://git.kernel.org/stable/c/6772c4868a8e7ad5305957cdb834ce881793acb7
- https://git.kernel.org/stable/c/89add40066f9ed9abe5f7f886fe5789ff7e0c50e
- https://git.kernel.org/stable/c/f01c5e335fbb7fb612d40f14a3c02e2612a43d3b
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46686
In the Linux kernel, the following vulnerability has been resolved: smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req() This happens when called from SMB2_read() while using rdma and reaching the rdma_readwrite_threshold.
- https://git.kernel.org/stable/c/6df57c63c200cd05e085c3b695128260e21959b7
- https://git.kernel.org/stable/c/a01859dd6aebf826576513850a3b05992809e9d2
- https://git.kernel.org/stable/c/b902fb78ab21299e4dd1775e7e8d251d5c0735bc
- https://git.kernel.org/stable/c/c724b2ab6a46435b4e7d58ad2fbbdb7a318823cf
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2026-04-21
CVE-2024-46725
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix out-of-bounds write warning Check the ring type value to fix the out-of-bounds write warning
- https://git.kernel.org/stable/c/130bee397b9cd52006145c87a456fd8719390cb5
- https://git.kernel.org/stable/c/919f9bf9997b8dcdc132485ea96121e7d15555f9
- https://git.kernel.org/stable/c/a60d1f7ff62e453dde2d3b4907e178954d199844
- https://git.kernel.org/stable/c/be1684930f5262a622d40ce7a6f1423530d87f89
- https://git.kernel.org/stable/c/c253b87c7c37ec40a2e0c84e4a6b636ba5cd66b2
- https://git.kernel.org/stable/c/cf2db220b38301b6486a0f11da24a0f317de558c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46794
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix data leak in mmio_read() The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an address from the VMM. Sean noticed that mmio_read() unintentionally exposes the value of an initialized variable (val) on the stack to the VMM. This variable is only needed as an output value. It did not need to be passed to the VMM in the first place. Do not send the original value of *val to the VMM. [ dhansen: clarify what 'val' is used for. ]
- https://git.kernel.org/stable/c/26c6af49d26ffc377e392e30d4086db19eed0ef7
- https://git.kernel.org/stable/c/b55ce742afcb8e8189d82f2f1e635ba1b5a461fa
- https://git.kernel.org/stable/c/b6fb565a2d15277896583d471b21bc14a0c99661
- https://git.kernel.org/stable/c/ef00818c50cf55a3a56bd9a9fae867c92dfb84e7
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-46812
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip inactive planes within ModeSupportAndSystemConfiguration [Why] Coverity reports Memory - illegal accesses. [How] Skip inactive planes.
- https://git.kernel.org/stable/c/2fd32a65f2e78eff0862c8fdf7815ca6bb44fb2e
- https://git.kernel.org/stable/c/3300a039caf850376bc3416c808cd8879da412bb
- https://git.kernel.org/stable/c/4331ae2788e779b11f3aad40c04be6c64831f2a2
- https://git.kernel.org/stable/c/8406158a546441b73f0b216aedacbf9a1e5748fb
- https://git.kernel.org/stable/c/a54f7e866cc73a4cb71b8b24bb568ba35c8969df
- https://git.kernel.org/stable/c/ee9d6df6d9172917d9ddbd948bb882652d5ecd29
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html
Modified: 2025-11-03
CVE-2024-46828
In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: fix bulk flow accounting logic for host fairness In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state. This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again). Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the *increment* was made conditional, but the *decrement* was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX). AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right. This patch fixes the issue by introducing the same conditional check on decrement as is used on increment. The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that.
- https://git.kernel.org/stable/c/4a4eeefa514db570be025ab46d779af180e2c9bb
- https://git.kernel.org/stable/c/546ea84d07e3e324644025e2aae2d12ea4c5896e
- https://git.kernel.org/stable/c/549e407569e08459d16122341d332cb508024094
- https://git.kernel.org/stable/c/7725152b54d295b7da5e34c2f419539b30d017bd
- https://git.kernel.org/stable/c/cde71a5677971f4f1b69b25e854891dbe78066a4
- https://git.kernel.org/stable/c/d4a9039a7b3d8005b90c7b1a55a306444f0e5447
- https://git.kernel.org/stable/c/d7c01c0714c04431b5e18cf17a9ea68a553d1c3c
- https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-50060
In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.
- https://git.kernel.org/stable/c/a2493904e95ce94bbec819d8f7f03b99976eb25c
- https://git.kernel.org/stable/c/c2eadeafce2d385b3f6d26a7f31fee5aba2bbbb0
- https://git.kernel.org/stable/c/eac2ca2d682f94f46b1973bdf5e77d85d77b8e53
- https://git.kernel.org/stable/c/f4ce3b5d26ce149e77e6b8e8f2058aa80e5b034e
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-53129
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)
- https://git.kernel.org/stable/c/1e53059729691ca4d905118258b9fbd17d854174
- https://git.kernel.org/stable/c/4e47b99a7764b23a431bff6a3f91dfe77d294765
- https://git.kernel.org/stable/c/656dbd1c21c2c088c70059cdd43ec83e7d54ec4d
- https://git.kernel.org/stable/c/ab1c793f457f740ab7108cc0b1340a402dbf484d
- https://git.kernel.org/stable/c/bbf8bc7e75863942028131ae39c23118f62de6c0
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
Modified: 2025-11-03
CVE-2024-53130
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.
- https://git.kernel.org/stable/c/0a5014ad37c77ac6a2c525137c00a0e1724f6020
- https://git.kernel.org/stable/c/0ce59fb1c73fdd5b6028226aeb46259a0cdc0957
- https://git.kernel.org/stable/c/2026559a6c4ce34db117d2db8f710fe2a9420d5a
- https://git.kernel.org/stable/c/7af3309c7a2ef26831a67125b11c34a7e01c1b2a
- https://git.kernel.org/stable/c/86b19031dbc79abc378dfae357f6ea33ebeb0c95
- https://git.kernel.org/stable/c/b0e4765740040c44039282057ecacd7435d1d2ba
- https://git.kernel.org/stable/c/d904e4d845aafbcfd8a40c1df7d999f02f062be8
- https://git.kernel.org/stable/c/ffc440a76a0f476a7e6ea838ec0dc8e9979944d1
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Modified: 2025-11-03
CVE-2024-53131
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.
- https://git.kernel.org/stable/c/085556bf8c70e2629e02e79268dac3016a08b8bf
- https://git.kernel.org/stable/c/19c71cdd77973f99a9adc3190130bc3aa7ae5423
- https://git.kernel.org/stable/c/3b2a4fd9bbee77afdd3ed5a05a0c02b6cde8d3b9
- https://git.kernel.org/stable/c/59b49ca67cca7b007a5afd3de0283c8008157665
- https://git.kernel.org/stable/c/6438f3f42cda825f6f59b4e45ac3a1da28a6f2c9
- https://git.kernel.org/stable/c/77e47f89d32c2d72eb33d0becbce7abe14d061f4
- https://git.kernel.org/stable/c/b017697a517f8779ada4e8ce1c2c75dbf60a2636
- https://git.kernel.org/stable/c/cd45e963e44b0f10d90b9e6c0e8b4f47f3c92471
- https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Package kernel-image-std-kvm updated to version 5.10.176-alt1 for branch sisyphus in task 317733.
Closed vulnerabilities
Modified: 2025-08-19
BDU:2023-01218
Уязвимость функции ene_remove() (drivers/media/rc/ene_ir.c) драйвера инфракрасного приемника\передатчика ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии
Modified: 2024-09-30
BDU:2023-01280
Уязвимость функции _pick_next_task_rt() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-08-19
BDU:2023-02165
Уязвимость фильтра индексирования системы контроля трафика tcindex (net/sched/cls_tcindex.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2026-02-17
BDU:2025-12418
Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12788
Уязвимость модуля crypto/xts.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12857
Уязвимость функции udf_merge_extents() в модуле fs/udf/inode.c файловой системы OSTA-UDF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
Modified: 2026-02-17
BDU:2025-12901
Уязвимость модуля drivers/scsi/mpt3sas/mpt3sas_base.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-12975
Уязвимость функции pm_runtime_resume_and_get() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-02-17
BDU:2025-16229
Уязвимость функции ses_intf_remove() компонента scsi ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации
BDU:2026-01331
Уязвимость функции ses_enclosure_data_process() модуля drivers/scsi/ses.c драйвера устройств SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01496
Уязвимость функции radeon_atombios_fini() модуля drivers/gpu/drm/radeon/radeon_device.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Radion ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01502
Уязвимость функции bcmgenet_desc_rx() модуля drivers/net/ethernet/broadcom/genet/bcmgenet.c драйвера сетевых адаптеров Ethernet Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01521
Уязвимость функций ext4_mb_clear_bb() и ext4_free_blocks() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01525
Уязвимость функции brcmf_c_preinit_dcmds() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-01530
Уязвимость функции mt7601u_rx_next_seg_len() модуля drivers/net/wireless/mediatek/mt7601u/dma.c драйвера адаптеров беспроводной связи Mediatek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02175
Уязвимость функции brcmf_c_preinit_dcmds() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02260
Уязвимость функции pick_file() в модуле fs/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-02274
Уязвимость функции dm_resume() в модуле drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-02370
Уязвимость функции alpine_msix_init_domains() модуля drivers/irqchip/irq-alpine-msi.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2026-03-04
BDU:2026-02438
Уязвимость функции tcindex_set_parms() модуля net/sched/cls_tcindex.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02443
Уязвимость функции io_init() модуля drivers/mtd/ubi/build.c драйвера памяти MTD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02517
Уязвимость функции seqiv_aead_encrypt_complete2() модуля crypto/seqiv.c криптографической подсистемы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-02518
Уязвимость функции ath9k_hif_usb_rx_stream() модуля drivers/net/wireless/ath/ath9k/hif_usb.c драйвера адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, вызвать отказ в обслуживании
BDU:2026-03311
Уязвимость функции udf_file_write_iter() модуля fs/udf/file.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03323
Уязвимость функции do_rbd_add() модуля drivers/block/rbd.c драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03331
Уязвимость функции mtk_drm_bind() модуля drivers/gpu/drm/mediatek/mtk_drm_drv.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Mediatek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03341
Уязвимость функции allocate_mr_list() модуля fs/cifs/smbdirect.c файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03349
Уязвимость функции il4965_setup_deferred_work() модуля drivers/net/wireless/intel/iwlegacy/4965-mac.c драйвера адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03645
Уязвимость функции brcmf_netdev_start_xmit() модуля drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c драйвера адаптеров беспроводной связи Broadcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03646
Уязвимость функции ov2740_init_controls() модуля drivers/media/i2c/ov2740.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03739
Уязвимость функции lookup_rec() модуля kernel/trace/ftrace.c поддержки трассировки ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03768
Уязвимость функции lbs_init_adapter() модуля drivers/net/wireless/marvell/libertas/main.c драйвера адаптеров беспроводной связи Marvell ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03805
Уязвимость функции __smc_lgr_terminate() модуля net/smc/smc_core.c реализации семейства протоколов сокетов SMC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03836
Уязвимость функции alloc_wbufs() модуля fs/ubifs/super.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03853
Уязвимость функции drm_gem_shmem_mmap() модуля drivers/gpu/drm/drm_gem_shmem_helper.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03855
Уязвимость функции do_feature_check_call() модуля drivers/firmware/xilinx/zynqmp.c драйвера прошивок ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03856
Уязвимость функции ndlc_remove() модуля drivers/nfc/st-nci/ndlc.c драйвера NFC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03857
Уязвимость функции __nvmet_req_complete() модуля drivers/nvme/target/core.c драйвера NVME ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03858
Уязвимость функции smsc75xx_rx_fixup() модуля drivers/net/usb/smsc75xx.c драйвера сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03859
Уязвимость функции cfusbl_device_notify() модуля net/caif/caif_usb.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-03898
Уязвимость функции icc_node_destroy() модуля drivers/interconnect/core.c драйвера межсоединений ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03952
Уязвимость функции ubi_resize_volume() модуля drivers/mtd/ubi/vmt.c драйвера памяти MTD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03956
Уязвимость функции mdp5_crtc_reset() модуля drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03957
Уязвимость функции watchdog_cdev_register() модуля drivers/watchdog/watchdog_dev.c поддержки сторожевого таймера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03958
Уязвимость функции fdp_nci_i2c_read_device_properties() модуля drivers/nfc/fdp/i2c.c драйвера NFC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-03959
Уязвимость функции walk_stackframe() модуля arch/riscv/kernel/stacktrace.c подсистемы управления модулями платформы с архитектурой RISCV ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании
BDU:2026-03960
Уязвимость функции svc_stop_kthreads() модуля net/sunrpc/svc.c реализации протокола RPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04048
Уязвимость функции ov772x_probe() модуля drivers/media/i2c/ov772x.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04332
Уязвимость функции platform_irqchip_probe() модуля drivers/irqchip/irqchip.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04334
Уязвимость функции dc_construct_ctx() модуля drivers/gpu/drm/amd/display/dc/core/dc.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04339
Уязвимость функции mtk_drm_crtc_create() модуля drivers/gpu/drm/mediatek/mtk_drm_crtc.c драйвера инфраструктуры прямого рендеринга (DRI) видеокарт Mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04517
Уязвимость функции dasd_eckd_init() модуля drivers/s390/block/dasd_eckd.c драйвера блочных устройств на платформе S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04588
Уязвимость функции __ocfs2_move_extent() модуля fs/ocfs2/move_extents.c файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04606
Уязвимость функции fei_debugfs_add_attr() модуля kernel/fail_function.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04619
Уязвимость функции msm_dsi_host_init() модуля drivers/gpu/drm/msm/dsi/dsi_host.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04626
Уязвимость функции swap_inode_boot_loader() модуля fs/ext4/ioctl.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04627
Уязвимость функции ext4_expand_extra_isize_ea() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04628
Уязвимость функции gpio_ir_recv_remove() модуля drivers/media/rc/gpio-ir-recv.c драйвера мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04629
Уязвимость функции ext4_xattr_inode_iget() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-04871
Уязвимость функции ila_xlat_nl_cmd_get_mapping() модуля net/ipv6/ila/ila_xlat.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05738
Уязвимость функции cfg80211_sme_connect() модуля net/wireless/sme.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05793
Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05852
Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05873
Уязвимость функции in_atomic() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05899
Уязвимость функции debugfs_lookup() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-05976
Уязвимость функции vkms_release() модуля drivers/gpu/drm/vkms/vkms_drv.c драйвера инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-05987
Уязвимость функции ti_sci_intr_irq_domain_probe() модуля drivers/irqchip/irq-ti-sci-intr.c драйвера IRQ-чипов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
BDU:2026-06003
Уязвимость функции hi3660_thermal_probe() модуля drivers/thermal/hisi_thermal.c драйвера управления температурой ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06022
Уязвимость функции ubi_wl_put_peb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации
BDU:2026-06074
Уязвимость функции _rtl8812ae_phy_set_txpower_limit() в модуле drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации
BDU:2026-06102
Уязвимость функции rt6_nlmsg_size() в модуле net/ipv6/route.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-11-13
CVE-2022-50021
In the Linux kernel, the following vulnerability has been resolved:
ext4: block range must be validated before use in ext4_mb_clear_bb()
Block range to free is validated in ext4_free_blocks() using
ext4_inode_block_valid() and then it's passed to ext4_mb_clear_bb().
However in some situations on bigalloc file system the range might be
adjusted after the validation in ext4_free_blocks() which can lead to
troubles on corrupted file systems such as one found by syzkaller that
resulted in the following BUG
kernel BUG at fs/ext4/ext4.h:3319!
PREEMPT SMP NOPTI
CPU: 28 PID: 4243 Comm: repro Kdump: loaded Not tainted 5.19.0-rc6+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
RIP: 0010:ext4_free_blocks+0x95e/0xa90
Call Trace:
Modified: 2025-11-19
CVE-2022-50226
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak For some sev ioctl interfaces, input may be passed that is less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the buffer, the sev ioctl interfaces with the issue may return uninitialized slab memory. Currently, all of the ioctl interfaces in the ccp driver are safe, but to prevent future problems, change all ioctl interfaces that allocate memory with kmalloc to use kzalloc and memset the data buffer to zero in sev_ioctl_do_platform_status.
- https://git.kernel.org/stable/c/13dc15a3f5fd7f884e4bfa8c011a0ae868df12ae
- https://git.kernel.org/stable/c/4c5300f6f5e18b11c02a92f136e69b98fddba15e
- https://git.kernel.org/stable/c/caa395aa16e7c9193fd7fa6cde462dd8229d4953
- https://git.kernel.org/stable/c/e11fb0a3a39bb42da35fa662c46ce7391f277436
- https://git.kernel.org/stable/c/f2a920daa780956b987c14b9f23de7c3c8915bf2
Modified: 2025-11-25
CVE-2022-50258
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds() This patch fixes a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware version string by memcpy() in brcmf_fil_iovar_data_get(). The patch ensures buf is null-terminated. Found by a modified version of syzkaller. [ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3 [ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 47.601565][ T1897] ================================================================== [ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0 [ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897 [ 47.604336][ T1897] [ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131 [ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event [ 47.607453][ T1897] Call Trace: [ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1 [ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334 [ 47.609009][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609434][ T1897] ? strsep+0x1b2/0x1f0 [ 47.609863][ T1897] kasan_report.cold+0x83/0xdf [ 47.610366][ T1897] ? strsep+0x1b2/0x1f0 [ 47.610882][ T1897] strsep+0x1b2/0x1f0 [ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0 [ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40 [ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0 [ 47.614704][ T1897] ? find_held_lock+0x2d/0x110 [ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260 [ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 47.616288][ T1897] brcmf_attach+0x246/0xd40 [ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0 [ 47.617280][ T1897] ? kmemdup+0x43/0x50 [ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690 [ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760 [ 47.619429][ T1897] ? usb_probe_device+0x250/0x250 [ 47.619950][ T1897] really_probe+0x205/0xb70 [ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.622209][ T1897] driver_probe_device+0x4e/0x150 [ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0 [ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0 [ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30 [ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160 [ 47.625437][ T1897] __device_attach+0x23f/0x3a0 [ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0 [ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0 [ 47.627057][ T1897] bus_probe_device+0x1da/0x290 [ 47.627557][ T1897] device_add+0xb7b/0x1eb0 [ 47.628027][ T1897] ? wait_for_completion+0x290/0x290 [ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0 [ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0 [ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0 [ 47.630385][ T1897] usb_probe_device+0xbb/0x250 [ 47.630927][ T1897] ? usb_suspend+0x590/0x590 [ 47.631397][ T1897] really_probe+0x205/0xb70 [ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130 [ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0 [ 47.633002][ ---truncated---
- https://git.kernel.org/stable/c/0a06cadcc2a0044e4a117cc0e61436fc3a0dad69
- https://git.kernel.org/stable/c/17dbe90e13f52848c460d253f15b765038ec6dc0
- https://git.kernel.org/stable/c/3a3a5e3f94068cd562d62a57da6983c8cd07d53c
- https://git.kernel.org/stable/c/881f50d76c3892262730ddf5c894eb00310e736c
- https://git.kernel.org/stable/c/89243a7b0ea19606ba1c2873c9d569026ccb344f
- https://git.kernel.org/stable/c/ba166e0ebdde3dfa833f0a3edaf2b2934d4a87f7
- https://git.kernel.org/stable/c/d481fd6064bf215d7c5068e15aa390c3b16c9cd0
- https://git.kernel.org/stable/c/d6ef66194bb4a6c18f5b9649bf62597909b040e4
Modified: 2025-12-03
CVE-2022-50279
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()
There is a global-out-of-bounds reported by KASAN:
BUG: KASAN: global-out-of-bounds in
_rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411
CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D
6.1.0-rc8+ #144 e15588508517267d37
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
Call Trace:
- https://git.kernel.org/stable/c/057b52461dc005ecd85a3e4998913b1492ec0f72
- https://git.kernel.org/stable/c/0c962dcd6bf64b78eaffc09e497a2beb4e48bc32
- https://git.kernel.org/stable/c/117dbeda22ec5ea0918254d03b540ef8b8a64d53
- https://git.kernel.org/stable/c/1e950b9a841bc96e98ee25680d5c7aa305120be1
- https://git.kernel.org/stable/c/28ea268d95e57cdf6394a058f0d854206d478772
- https://git.kernel.org/stable/c/f1fe40120de6ad4ffa8299fde035a5feba10d4fb
- https://git.kernel.org/stable/c/fc3442247716fc426bbcf62ed65e086e48a6d44f
Modified: 2025-12-03
CVE-2022-50294
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in lbs_init_adapter() When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not released. Add free memory to processing error path.
- https://git.kernel.org/stable/c/037f84c0bfae5c436c651d0e804264e2648010ec
- https://git.kernel.org/stable/c/16a03958618fb91bb1bc7077cf3211055162cc2f
- https://git.kernel.org/stable/c/23b34e08de5c2380414c9d3c33e8235094bcccae
- https://git.kernel.org/stable/c/4c102ad59bfa66c0f6662af64fa3b9007b02c20f
- https://git.kernel.org/stable/c/653d13a73e498d0bb6aeaf689aaa960defa7878b
- https://git.kernel.org/stable/c/98e0ff6980c89239d9e5d3da90d791c2383dc23a
- https://git.kernel.org/stable/c/9c8f50c7433bdfba1588831c413136ecc3f29f99
- https://git.kernel.org/stable/c/d46c33f667b05c22bc5c5b69aa730349c4b6fe31
Modified: 2025-12-03
CVE-2022-50321
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix potential memory leak in brcmf_netdev_start_xmit() The brcmf_netdev_start_xmit() returns NETDEV_TX_OK without freeing skb in case of pskb_expand_head() fails, add dev_kfree_skb() to fix it. Compile tested only.
- https://git.kernel.org/stable/c/212fde3fe76e962598ce1d47b97cc78afdfc71b3
- https://git.kernel.org/stable/c/3a4d18318f473e97d628f410215b3fac32d07aed
- https://git.kernel.org/stable/c/4c55fdebc1c358de96bfab52ed309d58a3ba66ef
- https://git.kernel.org/stable/c/7f159116d620615779adbf88a5d94713702216d8
- https://git.kernel.org/stable/c/d869a189505224601e310c7769cb90b0e2f60b31
- https://git.kernel.org/stable/c/e08e6812efb6a8c676e733de0518594d1517e0d9
- https://git.kernel.org/stable/c/e5d01e85cf46628647cd696cb72ba4659b18967f
- https://git.kernel.org/stable/c/e8ef89e5b89ee041a94eecfb6c31fcc237f9168c
Modified: 2026-01-14
CVE-2022-50369
In the Linux kernel, the following vulnerability has been resolved:
drm/vkms: Fix null-ptr-deref in vkms_release()
A null-ptr-deref is triggered when it tries to destroy the workqueue in
vkms->output.composer_workq in vkms_release().
KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24
RIP: 0010:destroy_workqueue+0x2f/0x710
...
Call Trace:
- https://git.kernel.org/stable/c/0b8f390e2251191f1b179cc87f65d54c96565f0d
- https://git.kernel.org/stable/c/1f9836f95271e7acf016667eee0aeae3386f9645
- https://git.kernel.org/stable/c/2fe2a8f40c21161ffe7653cc234e7934db5b7cc5
- https://git.kernel.org/stable/c/57031c474c3a920ea73afeb5dc352e537f5793ee
- https://git.kernel.org/stable/c/596f1ba3987e601e31a5abf1f75ce1d2635aceac
Modified: 2026-01-14
CVE-2022-50396
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix memory leak in tcindex_set_parms
Syzkaller reports a memory leak as follows:
====================================
BUG: memory leak
unreferenced object 0xffff88810c287f00 (size 256):
comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b
- https://git.kernel.org/stable/c/18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6
- https://git.kernel.org/stable/c/372ae77cf11d11fb118cbe2d37def9dd5f826abd
- https://git.kernel.org/stable/c/399ab7fe0fa0d846881685fd4e57e9a8ef7559f7
- https://git.kernel.org/stable/c/3abebc503a5148072052c229c6b04b329a420ecd
- https://git.kernel.org/stable/c/53af9c793f644d5841d84d8e0ad83bd7ab47f3e0
- https://git.kernel.org/stable/c/55ac68b53f1cea1926ee2313afc5d66b91daad71
- https://git.kernel.org/stable/c/6c55953e232ea668731091d111066521f3b7719b
- https://git.kernel.org/stable/c/7a6fb69bbcb21e9ce13bdf18c008c268874f0480
- https://git.kernel.org/stable/c/7c183dc0af472dec33d2c0786a5e356baa8cad19
- https://git.kernel.org/stable/c/b314f6c3512108d7a656c5caf07c82d1bbbdc0f1
- https://git.kernel.org/stable/c/c4de6057e7c6654983acb63d939d26ac0d7bbf39
- https://git.kernel.org/stable/c/facc4405e8b7407e03216207b1d1d640127de0c8
Modified: 2026-03-25
CVE-2022-50488
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible uaf for 'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10: ================================================================== BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups") changes that move process to a new cgroup will allocate a new bfqq to use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) | Λ | Λ | | | | V | V | bfqq1 bfqq2 2) bfqq1 is merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | Λ | | V | bfqq2(coop) 4) Before IOA is completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2) Λ |\--------------\ | V bfqq2 bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic.
- https://git.kernel.org/stable/c/094f3d9314d67691cb21ba091c1b528f6e3c4893
- https://git.kernel.org/stable/c/5533742c7cb1bc9b1f0bf401cc397d44a3a9e07a
- https://git.kernel.org/stable/c/64dc8c732f5c2b406cc752e6aaa1bd5471159cab
- https://git.kernel.org/stable/c/761564d93c8265f65543acf0a576b32d66bfa26a
- https://git.kernel.org/stable/c/b22fd72bfebda3956efc4431b60ddfc0a51e03e0
Modified: 2026-03-17
CVE-2022-50535
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential null-deref in dm_resume [Why] Fixing smatch error: dm_resume() error: we previously assumed 'aconnector->dc_link' could be null [How] Check if dc_link null at the beginning of the loop, so further checks can be dropped.
- https://git.kernel.org/stable/c/00b655fa96b4e941351cc4bf5ca755a65ae94a8e
- https://git.kernel.org/stable/c/7a7175a2cd84b7874bebbf8e59f134557a34161b
- https://git.kernel.org/stable/c/8e365f1bd672cc9320a936f6ae6f8087aa40e9bc
- https://git.kernel.org/stable/c/9f73793b81637c60ccc83cc508645310b8ab7d80
- https://git.kernel.org/stable/c/bb9a5562beb982aa5ebb73c521c49596ff8b8030
- https://git.kernel.org/stable/c/d236103782de25736996a45bd36ac2a89bdc93c6
- https://git.kernel.org/stable/c/fd79b61af2782f8875c78f50cdb8630ec43e2990
Modified: 2024-11-21
CVE-2023-1077
In the Linux kernel, pick_next_rt_entity() may return a type confused entry, not detected by the BUG_ON condition, as the confused entry will not be NULL, but list_head.The buggy error condition would lead to a type confused entry with the list head,which would then be used as a type confused sched_rt_entity,causing memory corruption.
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230511-0002/
- https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html
- https://security.netapp.com/advisory/ntap-20230511-0002/
Modified: 2025-04-23
CVE-2023-1118
A flaw use after free in the Linux kernel integrated infrared receiver/transceiver driver was found in the way user detaching rc device. A local user could use this flaw to crash the system or potentially escalate their privileges on the system.
- https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230413-0003/
- https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230413-0003/
Modified: 2025-02-13
CVE-2023-1829
A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation. The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure. A local attacker user can use this vulnerability to elevate its privileges to root. We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28.
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230601-0001/
- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28
- https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html
- https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html
- https://security.netapp.com/advisory/ntap-20230601-0001/
Modified: 2025-11-12
CVE-2023-53075
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix invalid address access in lookup_rec() when index is 0 KASAN reported follow problem: BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly added to ftrace_pages_start in ftrace_process_locs(). Before the first pg->index++, index is 0 and accessing pg->records[-1].ip will cause this problem. Don't check the ip when pg->index is 0.
- https://git.kernel.org/stable/c/2a0d71fabfeb349216d33f001a6421b1768bd3a9
- https://git.kernel.org/stable/c/2de28e5ce34b22b73b833a21e2c45ae3aade3964
- https://git.kernel.org/stable/c/4f84f31f63416b0f02fc146ffdc4ab32723eb7e8
- https://git.kernel.org/stable/c/7569ee04b0e3b32df79f64db3a7138573edad9bc
- https://git.kernel.org/stable/c/83c3b2f4e7c61367c7b24551f4c6eb94bbdda283
- https://git.kernel.org/stable/c/ac58b88ccbbb8e9fb83e137cee04a856b1ea6635
- https://git.kernel.org/stable/c/ee92fa443358f4fc0017c1d0d325c27b37802504
- https://git.kernel.org/stable/c/f1bd8b7fd890d87d0dc4dedc6287ea34dd07c0b4
Modified: 2025-11-12
CVE-2023-53077
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes [WHY] When PTEBufferSizeInRequests is zero, UBSAN reports the following warning because dml_log2 returns an unexpected negative value: shift exponent 4294966273 is too large for 32-bit type 'int' [HOW] In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and assign the result directly.
- https://git.kernel.org/stable/c/031f196d1b1b6d5dfcb0533b431e3ab1750e6189
- https://git.kernel.org/stable/c/7257070be70e19a9138f39009c1a26c83a8a7cfa
- https://git.kernel.org/stable/c/a16394b5d661afec9a264fecac3abd87aea439ea
- https://git.kernel.org/stable/c/bec1bea2fa974e63f6059c33edde669c7894d0bc
- https://git.kernel.org/stable/c/e12b95680821b9880cd9992c0f3555389363604f
Modified: 2025-11-12
CVE-2023-53084
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove another errant put in error path drm_gem_shmem_mmap() doesn't own reference in error code path, resulting in the dma-buf shmem GEM object getting prematurely freed leading to a later use-after-free.
- https://git.kernel.org/stable/c/5cfb617967b05f8f27e862c97db1fabd8485f4db
- https://git.kernel.org/stable/c/684c7372bbd6447c2e86a2a84e97a1478604d21f
- https://git.kernel.org/stable/c/77d26c824aa5a7e0681ef1d5b75fe538d746addc
- https://git.kernel.org/stable/c/dede8c14a37a7ac458f9add56154a074ed78e7cf
- https://git.kernel.org/stable/c/ee9adb7a45516cfa536ca92253d7ae59d56db9e4
Modified: 2025-11-12
CVE-2023-53087
In the Linux kernel, the following vulnerability has been resolved: drm/i915/active: Fix misuse of non-idle barriers as fence trackers Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed at an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel context and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. When adding a request to a composite tracker, we try to reuse an existing fence tracker, already allocated and registered with that composite. The tracker we obtain may already track another fence, may be an idle barrier, or an active barrier. If the tracker we get occurs a non-idle barrier then we try to delete that barrier from a list of barrier tasks it belongs to. However, while doing that we don't respect return value from a function that performs the barrier deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since the same structure field is reused with both fence callback lists and barrier tasks list, list corruptions would likely occur. Barriers are now deleted from a barrier tasks list by temporarily removing the list content, traversing that content with skip over the node to be deleted, then populating the list back with the modified content. Should that intentionally racy concurrent deletion attempts be not serialized, one or more of those may fail because of the list being temporary empty. Related code that ignores the results of barrier deletion was initially introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"). However, all users of the barrier deletion routine were apparently serialized at that time, then the issue didn't exhibit itself. Results of git bisect with help of a newly developed igt@gem_barrier_race@remote-request IGT test indicate that list corruptions might start to appear after commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), introduced in v5.5. Respect results of barrier deletion attempts -- mark the barrier as idle only if successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails then don't use that tracker but go back and try to acquire a new, usable one. v3: use unlikely() to document what outcome we expect (Andi), - fix bad grammar in commit description. v2: no code changes, - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"), v5.4, - reword commit description. (cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7)
- https://git.kernel.org/stable/c/5c7591b8574c52c56b3994c2fbef1a3a311b5715
- https://git.kernel.org/stable/c/5e784a7d07af42057c0576fb647b482f4cb0dc2c
- https://git.kernel.org/stable/c/6ab7d33617559cced63d467928f478ea5c459021
- https://git.kernel.org/stable/c/9159db27fb19bbf1c91b5c9d5285e66cc96cc5ff
- https://git.kernel.org/stable/c/e0e6b416b25ee14716f3549e0cbec1011b193809
Modified: 2025-11-12
CVE-2023-53089
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix task hung in ext4_xattr_delete_inode
Syzbot reported a hung task problem:
==================================================================
INFO: task syz-executor232:5073 blocked for more than 143 seconds.
Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004
Call Trace:
- https://git.kernel.org/stable/c/0f7bfd6f8164be32dbbdf36aa1e5d00485c53cd7
- https://git.kernel.org/stable/c/1aec41c98cce61d19ce89650895e51b9f3cdef13
- https://git.kernel.org/stable/c/2c96c52aeaa6fd9163cfacdd98778b4a0398ef18
- https://git.kernel.org/stable/c/64b72f5e7574020dea62ab733d88a54d903c42a1
- https://git.kernel.org/stable/c/73f7987fe1b82596f1a380e85cd0097ebaae7e01
- https://git.kernel.org/stable/c/94fd091576b12540924f6316ebc0678e84cb2800
- https://git.kernel.org/stable/c/a98160d8f3e6242ca9b7f443f26e7ef3a61ba684
- https://git.kernel.org/stable/c/efddc7e106fdf8d1f62d45e79de78f63b7c04fba
Modified: 2025-11-12
CVE-2023-53090
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix an illegal memory access In the kfd_wait_on_events() function, the kfd_event_waiter structure is allocated by alloc_event_waiters(), but the event field of the waiter structure is not initialized; When copy_from_user() fails in the kfd_wait_on_events() function, it will enter exception handling to release the previously allocated memory of the waiter structure; Due to the event field of the waiters structure being accessed in the free_waiters() function, this results in illegal memory access and system crash, here is the crash log: localhost kernel: RIP: 0010:native_queued_spin_lock_slowpath+0x185/0x1e0 localhost kernel: RSP: 0018:ffffaa53c362bd60 EFLAGS: 00010082 localhost kernel: RAX: ff3d3d6bff4007cb RBX: 0000000000000282 RCX: 00000000002c0000 localhost kernel: RDX: ffff9e855eeacb80 RSI: 000000000000279c RDI: ffffe7088f6a21d0 localhost kernel: RBP: ffffe7088f6a21d0 R08: 00000000002c0000 R09: ffffaa53c362be64 localhost kernel: R10: ffffaa53c362bbd8 R11: 0000000000000001 R12: 0000000000000002 localhost kernel: R13: ffff9e7ead15d600 R14: 0000000000000000 R15: ffff9e7ead15d698 localhost kernel: FS: 0000152a3d111700(0000) GS:ffff9e855ee80000(0000) knlGS:0000000000000000 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 localhost kernel: CR2: 0000152938000010 CR3: 000000044d7a4000 CR4: 00000000003506e0 localhost kernel: Call Trace: localhost kernel: _raw_spin_lock_irqsave+0x30/0x40 localhost kernel: remove_wait_queue+0x12/0x50 localhost kernel: kfd_wait_on_events+0x1b6/0x490 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: kfd_ioctl+0x38c/0x4a0 [hydcu] localhost kernel: ? kfd_ioctl_set_trap_handler+0x70/0x70 [hydcu] localhost kernel: ? kfd_ioctl_create_queue+0x5a0/0x5a0 [hydcu] localhost kernel: ? ftrace_graph_caller+0xa0/0xa0 localhost kernel: __x64_sys_ioctl+0x8e/0xd0 localhost kernel: ? syscall_trace_enter.isra.18+0x143/0x1b0 localhost kernel: do_syscall_64+0x33/0x80 localhost kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 localhost kernel: RIP: 0033:0x152a4dff68d7 Allocate the structure with kcalloc, and remove redundant 0-initialization and a redundant loop condition check.
- https://git.kernel.org/stable/c/2fece63b55c5d74cd6f5de51159e2cde37e10555
- https://git.kernel.org/stable/c/4fc8fff378b2f2039f2a666d9f8c570f4e58352c
- https://git.kernel.org/stable/c/5a3fb3b745af0ce46ec2e0c8e507bae45b937334
- https://git.kernel.org/stable/c/61f306f8df0d5559659c5578cf6d95236bcdcb25
- https://git.kernel.org/stable/c/6936525142a015e854d0a23e9ad9ea0a28b3843d
- https://git.kernel.org/stable/c/bbf5eada4334a96e3a204b2307ff5b14dc380b0b
- https://git.kernel.org/stable/c/d9923e7214a870b312bf61f6a89c7554d0966985
Modified: 2025-11-12
CVE-2023-53096
In the Linux kernel, the following vulnerability has been resolved: interconnect: fix mem leak when freeing nodes The node link array is allocated when adding links to a node but is not deallocated when nodes are destroyed.
- https://git.kernel.org/stable/c/2e0b13a1827229a02abef97b50ffaf89ba25370a
- https://git.kernel.org/stable/c/3167306455d0fbbbcf08cb25651acc527a86a95e
- https://git.kernel.org/stable/c/a5904f415e1af72fa8fe6665aa4f554dc2099a95
- https://git.kernel.org/stable/c/c1722e4113281fb34e5b4fb5c5387b17cd39a537
- https://git.kernel.org/stable/c/efae80ca13faa94457208852825731da44a788ad
- https://git.kernel.org/stable/c/f1e3a20c60196c37a402c584d0c9de306ba988ce
Modified: 2025-11-12
CVE-2023-53098
In the Linux kernel, the following vulnerability has been resolved: media: rc: gpio-ir-recv: add remove function In case runtime PM is enabled, do runtime PM clean up to remove cpu latency qos request, otherwise driver removal may have below kernel dump: [ 19.463299] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048 [ 19.472161] Mem abort info: [ 19.474985] ESR = 0x0000000096000004 [ 19.478754] EC = 0x25: DABT (current EL), IL = 32 bits [ 19.484081] SET = 0, FnV = 0 [ 19.487149] EA = 0, S1PTW = 0 [ 19.490361] FSC = 0x04: level 0 translation fault [ 19.495256] Data abort info: [ 19.498149] ISV = 0, ISS = 0x00000004 [ 19.501997] CM = 0, WnR = 0 [ 19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000 [ 19.511432] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000 [ 19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last unloaded: rc_core] [ 19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted 6.2.0-rc1-00028-g2c397a46d47c #72 [ 19.531854] Hardware name: FSL i.MX8MM EVK board (DT) [ 19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110 [ 19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.557294] sp : ffff800008ce3740 [ 19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27: ffff800008ce3d50 [ 19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24: ffffc7e3f9ef0e30 [ 19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21: 0000000000000008 [ 19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18: ffffffffffffffff [ 19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15: ffffffffffffffff [ 19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12: 0000000000000001 [ 19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 : 0000000000000008 [ 19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 000000000f0bfe9f [ 19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 : ffff006180382010 [ 19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 : 0000000000000020 [ 19.638548] Call trace: [ 19.640995] cpu_latency_qos_remove_request+0x20/0x110 [ 19.646142] gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv] [ 19.652339] pm_generic_runtime_suspend+0x2c/0x44 [ 19.657055] __rpm_callback+0x48/0x1dc [ 19.660807] rpm_callback+0x6c/0x80 [ 19.664301] rpm_suspend+0x10c/0x640 [ 19.667880] rpm_idle+0x250/0x2d0 [ 19.671198] update_autosuspend+0x38/0xe0 [ 19.675213] pm_runtime_set_autosuspend_delay+0x40/0x60 [ 19.680442] gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv] [ 19.685941] platform_probe+0x68/0xc0 [ 19.689610] really_probe+0xc0/0x3dc [ 19.693189] __driver_probe_device+0x7c/0x190 [ 19.697550] driver_probe_device+0x3c/0x110 [ 19.701739] __driver_attach+0xf4/0x200 [ 19.705578] bus_for_each_dev+0x70/0xd0 [ 19.709417] driver_attach+0x24/0x30 [ 19.712998] bus_add_driver+0x17c/0x240 [ 19.716834] driver_register+0x78/0x130 [ 19.720676] __platform_driver_register+0x28/0x34 [ 19.725386] gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv] [ 19.731404] do_one_initcall+0x44/0x2ac [ 19.735243] do_init_module+0x48/0x1d0 [ 19.739003] load_module+0x19fc/0x2034 [ 19.742759] __do_sys_finit_module+0xac/0x12c [ 19.747124] __arm64_sys_finit_module+0x20/0x30 [ 19.751664] invoke_syscall+0x48/0x114 [ 19.755420] el0_svc_common.constprop.0+0xcc/0xec [ 19.760132] do_el0_svc+0x38/0xb0 [ 19.763456] el0_svc+0x2c/0x84 [ 19.766516] el0t_64_sync_handler+0xf4/0x120 [ 19.770789] el0t_64_sync+0x190/0x194 [ 19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400) [ 19.780556] ---[ end trace 0000000000000000 ]---
- https://git.kernel.org/stable/c/00e81f191bc00cb6faabf468960e96ebf0404a6c
- https://git.kernel.org/stable/c/2ece4d2f7eac1cb51dc0e9859e09bfdb00faa28e
- https://git.kernel.org/stable/c/30040818b338b8ebc956ce0ebd198f8d593586a6
- https://git.kernel.org/stable/c/513572bb89e8075f5d2a2bb4c89f1152e44da9d8
- https://git.kernel.org/stable/c/a5c140d88a69eb43de2a030f1d7ff7b16bff3b1a
Modified: 2025-11-10
CVE-2023-53099
In the Linux kernel, the following vulnerability has been resolved:
firmware: xilinx: don't make a sleepable memory allocation from an atomic context
The following issue was discovered using lockdep:
[ 6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209
[ 6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0
[ 6.702431] 2 locks held by swapper/0/1:
[ 6.706300] #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4c/0x90
[ 6.714900] #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, at: clk_enable_lock+0x4c/0x140
[ 6.723156] irq event stamp: 304030
[ 6.726596] hardirqs last enabled at (304029): [
- https://git.kernel.org/stable/c/162049c31eb64308afa22e341a257a723526eb5c
- https://git.kernel.org/stable/c/38ed310c22e7a0fc978b1f8292136a4a4a8b3051
- https://git.kernel.org/stable/c/86afb633beaa02ee95b5126a14c9f22cfade4fd9
- https://git.kernel.org/stable/c/9bbab2843f2d1337a268499a1c02b435d2985a17
- https://git.kernel.org/stable/c/b37d3ccbd549494890672136a0e623eb010d46a7
Modified: 2025-11-10
CVE-2023-53100
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix WARNING in ext4_update_inline_data
Syzbot found the following issue:
EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.
fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-aesni"
fscrypt: AES-256-XTS using implementation "xts-aes-aesni"
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
Modules linked in:
CPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525
RSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246
RAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000
RDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248
RBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220
R10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40
R13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c
FS: 0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
- https://git.kernel.org/stable/c/2b96b4a5d9443ca4cad58b0040be455803c05a42
- https://git.kernel.org/stable/c/35161cec76772f74526f5886ad4082ec48511d5c
- https://git.kernel.org/stable/c/39c5df2ca544368b44b59d0f6d80131e90763371
- https://git.kernel.org/stable/c/74d775083e9f3d9dadf9e3b5f3e0028d1ad0bd5c
- https://git.kernel.org/stable/c/92eee6a82a9a6f9f83559e17a2b6b935e1a5cd25
- https://git.kernel.org/stable/c/a9bd94f67b27739bbe8583c52256502bd4cc7e83
- https://git.kernel.org/stable/c/c5aa102b433b1890e1ccaa40c06826c77dda1665
- https://git.kernel.org/stable/c/ca500cf2eceb5a8e93bf71ab97b5f7a18ecabce2
Modified: 2025-11-10
CVE-2023-53101
In the Linux kernel, the following vulnerability has been resolved: ext4: zero i_disksize when initializing the bootloader inode If the boot loader inode has never been used before, the EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the i_size to 0. However, if the "never before used" boot loader has a non-zero i_size, then i_disksize will be non-zero, and the inconsistency between i_size and i_disksize can trigger a kernel warning: WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa RIP: 0010:ext4_file_write_iter+0xbc7/0xd10 Call Trace: vfs_write+0x3b1/0x5c0 ksys_write+0x77/0x160 __x64_sys_write+0x22/0x30 do_syscall_64+0x39/0x80 Reproducer: 1. create corrupted image and mount it: mke2fs -t ext4 /tmp/foo.img 200 debugfs -wR "sif <5> size 25700" /tmp/foo.img mount -t ext4 /tmp/foo.img /mnt cd /mnt echo 123 > file 2. Run the reproducer program: posix_memalign(&buf, 1024, 1024) fd = open("file", O_RDWR | O_DIRECT); ioctl(fd, EXT4_IOC_SWAP_BOOT); write(fd, buf, 1024); Fix this by setting i_disksize as well as i_size to zero when initiaizing the boot loader inode.
- https://git.kernel.org/stable/c/01a821aacc64d4b05dafd239dbc9b7856686002f
- https://git.kernel.org/stable/c/0d8a6c9a6415999fee1259ccf1796480c026b7d6
- https://git.kernel.org/stable/c/3f00c476da8fe7c4c34ea16abb55d74127120413
- https://git.kernel.org/stable/c/59eee0cdf8c036f554add97a4da7c06d7a9ff34a
- https://git.kernel.org/stable/c/9cb27b1e76f0cc886ac09055bc41c0ab3f205167
- https://git.kernel.org/stable/c/9e9a4cc5486356158554f6ad73027d8635a48b34
- https://git.kernel.org/stable/c/d6c1447e483c05dbcfb3ff77ac04237a82070b8c
- https://git.kernel.org/stable/c/f5361da1e60d54ec81346aee8e3d8baf1be0b762
Modified: 2025-11-10
CVE-2023-53102
In the Linux kernel, the following vulnerability has been resolved:
ice: xsk: disable txq irq before flushing hw
ice_qp_dis() intends to stop a given queue pair that is a target of xsk
pool attach/detach. One of the steps is to disable interrupts on these
queues. It currently is broken in a way that txq irq is turned off
*after* HW flush which in turn takes no effect.
ice_qp_dis():
-> ice_qvec_dis_irq()
--> disable rxq irq
--> flush hw
-> ice_vsi_stop_tx_ring()
-->disable txq irq
Below splat can be triggered by following steps:
- start xdpsock WITHOUT loading xdp prog
- run xdp_rxq_info with XDP_TX action on this interface
- start traffic
- terminate xdpsock
[ 256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018
[ 256.319560] #PF: supervisor read access in kernel mode
[ 256.324775] #PF: error_code(0x0000) - not-present page
[ 256.329994] PGD 0 P4D 0
[ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G OE 6.2.0-rc5+ #51
[ 256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019
[ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice]
[ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44
[ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206
[ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f
[ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80
[ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000
[ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000
[ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600
[ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000
[ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0
[ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 256.457770] PKRU: 55555554
[ 256.460529] Call Trace:
[ 256.463015]
- https://git.kernel.org/stable/c/243cde8de10894d7812c8a6b62653bf04d8f9700
- https://git.kernel.org/stable/c/2ecc6e44959382f95c9d427cd8da85121a9cecda
- https://git.kernel.org/stable/c/b830c9642386867863ac64295185f896ff2928ac
- https://git.kernel.org/stable/c/b89a453c6918e0f346fb0562e8c7812b94d28c73
- https://git.kernel.org/stable/c/cccba1ff0798a27f7b8d0c06762ef977400a2afb
Modified: 2025-11-10
CVE-2023-53106
In the Linux kernel, the following vulnerability has been resolved: nfc: st-nci: Fix use after free bug in ndlc_remove due to race condition This bug influences both st_nci_i2c_remove and st_nci_spi_remove. Take st_nci_i2c_remove as an example. In st_nci_i2c_probe, it called ndlc_probe and bound &ndlc->sm_work with llt_ndlc_sm_work. When it calls ndlc_recv or timeout handler, it will finally call schedule_work to start the work. When we call st_nci_i2c_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in ndlc_remove CPU0 CPU1 |llt_ndlc_sm_work st_nci_i2c_remove | ndlc_remove | st_nci_remove | nci_free_device| kfree(ndev) | //free ndlc->ndev | |llt_ndlc_rcv_queue |nci_recv_frame |//use ndlc->ndev
- https://git.kernel.org/stable/c/2156490c4b7cacda9a18ec99929940b8376dc0e3
- https://git.kernel.org/stable/c/3405eb641dafcc8b28d174784b203c1622c121bf
- https://git.kernel.org/stable/c/43aa468df246175207a7d5d7d6d31b231f15b49c
- https://git.kernel.org/stable/c/5000fe6c27827a61d8250a7e4a1d26c3298ef4f6
- https://git.kernel.org/stable/c/5e331022b448fbc5e76f24349cd0246844dcad25
- https://git.kernel.org/stable/c/84dd9cc34014e3a3dcce0eb6d54b8a067e97676b
- https://git.kernel.org/stable/c/b0c202a8dc63008205a5d546559736507a9aae66
- https://git.kernel.org/stable/c/f589e5b56c562d99ea74e05b1c3f0eab78aa17a3
Modified: 2025-11-10
CVE-2023-53108
In the Linux kernel, the following vulnerability has been resolved: net/iucv: Fix size of interrupt data iucv_irq_data needs to be 4 bytes larger. These bytes are not used by the iucv module, but written by the z/VM hypervisor in case a CPU is deconfigured. Reported as: BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten ----------------------------------------------------------------------------- 0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1 __kmem_cache_alloc_node+0x166/0x450 kmalloc_node_trace+0x3a/0x70 iucv_cpu_prepare+0x44/0xd0 cpuhp_invoke_callback+0x156/0x2f0 cpuhp_issue_call+0xf0/0x298 __cpuhp_setup_state_cpuslocked+0x136/0x338 __cpuhp_setup_state+0xf4/0x288 iucv_init+0xf4/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1 __kmem_cache_free+0x308/0x358 iucv_init+0x92/0x280 do_one_initcall+0x78/0x390 do_initcalls+0x11a/0x140 kernel_init_freeable+0x25e/0x2a0 kernel_init+0x2e/0x170 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0| Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000 Redzone 0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Object 0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object 0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2 ................ Object 0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc ................ Object 0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................ Redzone 0000000000400580: cc cc cc cc cc cc cc cc ........ Padding 00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ Padding 00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<000000032aa034ec>] dump_stack_lvl+0xac/0x100 [<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140 [<0000000329f5aa78>] check_object+0x370/0x3c0 [<0000000329f5ede6>] free_debug_processing+0x15e/0x348 [<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0 [<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8 [<0000000329f61768>] __kmem_cache_free+0x308/0x358 [<000000032a91465c>] iucv_cpu_dead+0x6c/0x88 [<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0 [<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0 [<0000000329c3243e>] cpu_device_down+0x4e/0x78 [<000000032a61dee0>] device_offline+0xc8/0x118 [<000000032a61e048>] online_store+0x60/0xe0 [<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8 [<0000000329fab65c>] vfs_write+0x174/0x360 [<0000000329fab9fc>] ksys_write+0x74/0x100 [<000000032aa03a5a>] __do_syscall+0x1da/0x208 [<000000032aa177b2>] system_call+0x82/0xb0 INFO: lockdep is turned off. FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc FIX dma-kmalloc-64: Object at 0x0000000000400540 not freed
- https://git.kernel.org/stable/c/3cfdefdaaa4b2a77e84d0db5e0a47a7aa3bb615a
- https://git.kernel.org/stable/c/3d87debb8ed2649608ff432699e7c961c0c6f03b
- https://git.kernel.org/stable/c/71da5991b6438ad6da13ceb25465ee2760a1c52f
- https://git.kernel.org/stable/c/93a970494881004c348d8feb38463ee72496e99a
- https://git.kernel.org/stable/c/a908eae0f71811afee86be7088692f1aa5855c3b
- https://git.kernel.org/stable/c/b0d2bb5e31a693ebc8888eb407f8a257a3680efa
- https://git.kernel.org/stable/c/bd2e78462ae18484e55ae4d285df2c86b86bdd12
- https://git.kernel.org/stable/c/c78f1345db4e4b3b78f9b768f4074ebd60abe966
Modified: 2025-11-10
CVE-2023-53109
In the Linux kernel, the following vulnerability has been resolved: net: tunnels: annotate lockless accesses to dev->needed_headroom IP tunnels can apparently update dev->needed_headroom in their xmit path. This patch takes care of three tunnels xmit, and also the core LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA() helpers. More changes might be needed for completeness. BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmit read to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1: ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:444 [inline] ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126 iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4881 [inline] netdev_start_xmit include/linux/netdevice.h:4895 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596 __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246 dev_queue_xmit include/linux/netdevice.h:3051 [inline] neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623 neigh_output include/net/neighbour.h:546 [inline] ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228 ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip_output+0xe5/0x1b0 net/i ---truncated---
- https://git.kernel.org/stable/c/4b397c06cb987935b1b097336532aa6b4210e091
- https://git.kernel.org/stable/c/51f3bd3765bc5ca4583af07a00833da00d2ace1d
- https://git.kernel.org/stable/c/5aaab217c8f5387b9c5fff9e940d80f135e04366
- https://git.kernel.org/stable/c/8e206f66d824b3b28a7f9ee1366dfc79a937bb46
- https://git.kernel.org/stable/c/9b86a8702b042ee4e15d2d46375be873a6a8834f
- https://git.kernel.org/stable/c/a69b72b57b7d269e833e520ba7500d556e8189b6
- https://git.kernel.org/stable/c/be59b87ee4aed81db7c10e44f603866a0ac3ca5d
- https://git.kernel.org/stable/c/e0a557fc1daf5c1086e47150a4571aebadbb62be
Modified: 2025-11-10
CVE-2023-53110
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler() When performing a stress test on SMC-R by rmmod mlx5_ib driver during the wrk/nginx test, we found that there is a probability of triggering a panic while terminating all link groups. This issue dues to the race between smc_smcr_terminate_all() and smc_buf_create(). smc_smcr_terminate_all smc_buf_create /* init */ conn->sndbuf_desc = NULL; ... __smc_lgr_terminate smc_conn_kill smc_close_abort smc_cdc_get_slot_and_msg_send __softirqentry_text_start smc_wr_tx_process_cqe smc_cdc_tx_handler READ(conn->sndbuf_desc->len); /* panic dues to NULL sndbuf_desc */ conn->sndbuf_desc = xxx; This patch tries to fix the issue by always to check the sndbuf_desc before send any cdc msg, to make sure that no null pointer is seen during cqe processing.
- https://git.kernel.org/stable/c/22a825c541d775c1dbe7b2402786025acad6727b
- https://git.kernel.org/stable/c/31817c530768b0199771ec6019571b4f0ddbf230
- https://git.kernel.org/stable/c/3c270435db8aa34929263dddae8fd050f5216ecb
- https://git.kernel.org/stable/c/3ebac7cf0a184a8102821a7a00203f02bebda83c
- https://git.kernel.org/stable/c/b108bd9e6be000492ebebe867daa699285978a10
Modified: 2025-11-10
CVE-2023-53114
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix kernel crash during reboot when adapter is in recovery mode
If the driver detects during probe that firmware is in recovery
mode then i40e_init_recovery_mode() is called and the rest of
probe function is skipped including pci_set_drvdata(). Subsequent
i40e_shutdown() called during shutdown/reboot dereferences NULL
pointer as pci_get_drvdata() returns NULL.
To fix call pci_set_drvdata() also during entering to recovery mode.
Reproducer:
1) Lets have i40e NIC with firmware in recovery mode
2) Run reboot
Result:
[ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver
[ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.
[ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.
[ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
[ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
[ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0
[ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.
[ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.
[ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]
[ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0
...
[ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2
[ 156.318330] #PF: supervisor write access in kernel mode
[ 156.323546] #PF: error_code(0x0002) - not-present page
[ 156.328679] PGD 0 P4D 0
[ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1
[ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022
[ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]
[ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00
- https://git.kernel.org/stable/c/3cbecb1c9085a00155639404f7addbcbfc987ba3
- https://git.kernel.org/stable/c/4ff82695266576a0b4f1077a7100b2451e476df4
- https://git.kernel.org/stable/c/6e18f66b704bd725196508c1db93bf7338cdc8de
- https://git.kernel.org/stable/c/7e4f8a0c495413a50413e8c9f1032ce1bc633bae
- https://git.kernel.org/stable/c/b3826fb3ea14646b3d4e6309bfc384b349f36eb6
- https://git.kernel.org/stable/c/c703362a66ea971905b9dc153fc54d1b6ac05423
Modified: 2025-11-10
CVE-2023-53116
In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid potential UAF in nvmet_req_complete() An nvme target ->queue_response() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpu_ref_put() is called in nvmet_req_complete(). Avoid such problem by using a local variable to save the sq pointer before calling __nvmet_req_complete(), thus avoiding dereferencing the req pointer after that function call.
- https://git.kernel.org/stable/c/04c394208831d5e0d5cfee46722eb0f033cd4083
- https://git.kernel.org/stable/c/6173a77b7e9d3e202bdb9897b23f2a8afe7bf286
- https://git.kernel.org/stable/c/8ed9813871038b25a934b21ab76b5b7dbf44fc3a
- https://git.kernel.org/stable/c/a6317235da8aa7cb97529ebc8121cc2a4c4c437a
- https://git.kernel.org/stable/c/bcd535f07c58342302a2cd2bdd8894fe0872c8a9
- https://git.kernel.org/stable/c/e5d99b29012bbf0e86929403209723b2806500c1
- https://git.kernel.org/stable/c/f1d5888a5efe345b63c430b256e95acb0a475642
- https://git.kernel.org/stable/c/fafcb4b26393870c45462f9af6a48e581dbbcf7e
Modified: 2025-11-10
CVE-2023-53117
In the Linux kernel, the following vulnerability has been resolved: fs: prevent out-of-bounds array speculation when closing a file descriptor Google-Bug-Id: 114199369
- https://git.kernel.org/stable/c/3d5d9501b634fd268eb56428cda92cd317752d69
- https://git.kernel.org/stable/c/609d54441493c99f21c1823dfd66fa7f4c512ff4
- https://git.kernel.org/stable/c/6631c8da02cfad96c53b217cf647b511c7f34faf
- https://git.kernel.org/stable/c/a759905de9cd6ec9ca08ceadf0920272772ed830
- https://git.kernel.org/stable/c/cec08b7d1ebcd3138d4658b3868ce26aeb1e8e06
- https://git.kernel.org/stable/c/eea8e4e056a5ffbeb539a13854c017d5d62c756a
- https://git.kernel.org/stable/c/f31cd5da636682caea424fa1c22679016cbfc16b
- https://git.kernel.org/stable/c/f8cd8754a03a3748384ee438c572423643c9c315
Modified: 2025-11-10
CVE-2023-53119
In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: initialize struct pn533_out_arg properly
struct pn533_out_arg used as a temporary context for out_urb is not
initialized properly. Its uninitialized 'phy' field can be dereferenced in
error cases inside pn533_out_complete() callback function. It causes the
following failure:
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441
Call Trace:
- https://git.kernel.org/stable/c/0f9c1f26d434c32520dfe33326b28c5954bc4299
- https://git.kernel.org/stable/c/2703da78849c47b6b5b4471edb35fc7b7f91dead
- https://git.kernel.org/stable/c/2bd1ed6d607d7013ed4959e86990a04f028543ef
- https://git.kernel.org/stable/c/2bee84369b76f6c9ef71938069c65a6ebd1a12f7
- https://git.kernel.org/stable/c/2cbd4213baf7be5d87d183e2032c54003de0790f
- https://git.kernel.org/stable/c/484b7059796e3bc1cb527caa61dfc60da649b4f6
- https://git.kernel.org/stable/c/4c20a07ed26a71a8ccc9c6d935fc181573f5462e
- https://git.kernel.org/stable/c/a97ef110c491b72c138111a595a3a3af56cbc94c
Modified: 2025-11-10
CVE-2023-53121
In the Linux kernel, the following vulnerability has been resolved:
tcp: tcp_make_synack() can be called from process context
tcp_rtx_synack() now could be called in process context as explained in
0a375c822497 ("tcp: tcp_rtx_synack() can be called from process
context").
tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU
variables with preemption enabled. This causes the following BUG:
BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464
caller is tcp_make_synack+0x841/0xac0
Call Trace:
- https://git.kernel.org/stable/c/442aa78ed70188b21ccd8669738448702c0a3281
- https://git.kernel.org/stable/c/7613cde8c0c1f02a7ec2e1d536c01b65b135fc1c
- https://git.kernel.org/stable/c/77ad58bca0119e8cc3e0e9d91a3f22caa66e4dfa
- https://git.kernel.org/stable/c/9180aa4622a720b433e842b4d3aa34d73eec577a
- https://git.kernel.org/stable/c/ad07290d63ff6689f50565b02f5b6f34ec15a5ca
- https://git.kernel.org/stable/c/bced3f7db95ff2e6ca29dc4d1c9751ab5e736a09
- https://git.kernel.org/stable/c/d493d4fe88195a144d6a277a90062a7534ed2192
- https://git.kernel.org/stable/c/e23ca307745be3df7fe9762f3e2a7e311a57852e
Modified: 2025-11-10
CVE-2023-53124
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add() Port is allocated by sas_port_alloc_num() and rphy is allocated by either sas_end_device_alloc() or sas_expander_alloc(), all of which may return NULL. So we need to check the rphy to avoid possible NULL pointer access. If sas_rphy_add() returned with failure, rphy is set to NULL. We would access the rphy in the following lines which would also result NULL pointer access.
- https://git.kernel.org/stable/c/090305c36185c0547e4441d4c08f1cf096b32134
- https://git.kernel.org/stable/c/6f0c2f70d9929208d8427ec72c3ed91e2251e289
- https://git.kernel.org/stable/c/9937f784a608944107dcc2ba9a9c3333f8330b9e
- https://git.kernel.org/stable/c/a26c775ccc4cfe46f9b718b51bd24313053c7e0b
- https://git.kernel.org/stable/c/b5e5bbb3fa5f8412e96c5eda7f4a4af6241d6bd3
- https://git.kernel.org/stable/c/d3c57724f1569311e4b81e98fad0931028b9bdcd
Modified: 2025-11-10
CVE-2023-53125
In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Limit packet length to skb->len Packet length retrieved from skb data may be larger than the actual socket buffer length (up to 9026 bytes). In such case the cloned skb passed up the network stack will leak kernel memory contents.
- https://git.kernel.org/stable/c/105db6574281e1e03fcbf87983f4fee111682306
- https://git.kernel.org/stable/c/4a4de0a68b18485c68ab4f0cfa665b1633c6d277
- https://git.kernel.org/stable/c/53966d572d056d6b234cfe76a5f9d60049d3c178
- https://git.kernel.org/stable/c/8ee5df9c039e37b9d8eb5e3de08bfb7f53d31cb6
- https://git.kernel.org/stable/c/9fabdd79051a9fe51388df099aff6e4b660fedd2
- https://git.kernel.org/stable/c/c7bdc137ca163b90917c1eeba4f1937684bd4f8b
- https://git.kernel.org/stable/c/d8b228318935044dafe3a5bc07ee71a1f1424b8d
- https://git.kernel.org/stable/c/e294f0aa47e4844f3d3c8766c02accd5a76a7d4e
Modified: 2025-11-10
CVE-2023-53131
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a server shutdown leak Fix a race where kthread_stop() may prevent the threadfn from ever getting called. If that happens the svc_rqst will not be cleaned up.
- https://git.kernel.org/stable/c/7a3720361068ab520aed4608bad31ea9a6cc7fe7
- https://git.kernel.org/stable/c/9ca6705d9d609441d34f8b853e1e4a6369b3b171
- https://git.kernel.org/stable/c/ad7e40ee157ba33950a4ccdc284334580da3638d
- https://git.kernel.org/stable/c/ce7dd61e004002bc1c48d1ca47c887f3f3cc7370
- https://git.kernel.org/stable/c/f74b3286859463cd63cc9d4aeaabd8b0c640182a
Modified: 2025-11-10
CVE-2023-53134
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Avoid order-5 memory allocation for TPA data The driver needs to keep track of all the possible concurrent TPA (GRO/LRO) completions on the aggregation ring. On P5 chips, the maximum number of concurrent TPA is 256 and the amount of memory we allocate is order-5 on systems using 4K pages. Memory allocation failure has been reported: NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1 Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022 Call Trace: dump_stack+0x57/0x6e warn_alloc.cold.120+0x7b/0xdd ? _cond_resched+0x15/0x30 ? __alloc_pages_direct_compact+0x15f/0x170 __alloc_pages_slowpath.constprop.108+0xc58/0xc70 __alloc_pages_nodemask+0x2d0/0x300 kmalloc_order+0x24/0xe0 kmalloc_order_trace+0x19/0x80 bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en] ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en] __bnxt_open_nic+0x12e/0x780 [bnxt_en] bnxt_open+0x10b/0x240 [bnxt_en] __dev_open+0xe9/0x180 __dev_change_flags+0x1af/0x220 dev_change_flags+0x21/0x60 do_setlink+0x35c/0x1100 Instead of allocating this big chunk of memory and dividing it up for the concurrent TPA instances, allocate each small chunk separately for each TPA instance. This will reduce it to order-0 allocations.
- https://git.kernel.org/stable/c/16f3aae1aa2dd89bc8d073a67f190af580386ae9
- https://git.kernel.org/stable/c/20fd0607acbf9770db9b99e3418dd75614f80b6c
- https://git.kernel.org/stable/c/accd7e23693aaaa9aa0d3e9eca0ae77d1be80ab3
- https://git.kernel.org/stable/c/ad529d1fae1565d38f929479d4ea8aea90054bd2
- https://git.kernel.org/stable/c/d16701a385b54f44bf41ff1d7485e7a11080deb3
- https://git.kernel.org/stable/c/fcae40e65802547def39b4deaa2ae38a29864d81
Modified: 2025-11-10
CVE-2023-53135
In the Linux kernel, the following vulnerability has been resolved:
riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode
When CONFIG_FRAME_POINTER is unset, the stack unwinding function
walk_stackframe randomly reads the stack and then, when KASAN is enabled,
it can lead to the following backtrace:
[ 0.000000] ==================================================================
[ 0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a
[ 0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0
[ 0.000000]
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43
[ 0.000000] Hardware name: riscv-virtio,qemu (DT)
[ 0.000000] Call Trace:
[ 0.000000] [
- https://git.kernel.org/stable/c/17fa90ffba20743c946920fbb0afe160d0ead8c9
- https://git.kernel.org/stable/c/324912d6c0c4006711054d389faa2239c1655e1e
- https://git.kernel.org/stable/c/3a9418d2c93c1c86ce4d0595112d91c7a8e70c2c
- https://git.kernel.org/stable/c/3de277af481ab931fab9e295ad8762692920732a
- https://git.kernel.org/stable/c/76950340cf03b149412fe0d5f0810e52ac1df8cb
- https://git.kernel.org/stable/c/a99a61d9e1bfca2fc37d223a6a185c0eb66aba02
Modified: 2025-11-10
CVE-2023-53138
In the Linux kernel, the following vulnerability has been resolved:
net: caif: Fix use-after-free in cfusbl_device_notify()
syzbot reported use-after-free in cfusbl_device_notify() [1]. This
causes a stack trace like below:
BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138
Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214
CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
- https://git.kernel.org/stable/c/1793da97a23e31c5bf06631f3f3e5a25f368fd64
- https://git.kernel.org/stable/c/287027d8a567168a5d8ce5cb0cba16a34791a48c
- https://git.kernel.org/stable/c/3f14457e1584224f4296af613bbd99deb60b5d91
- https://git.kernel.org/stable/c/68a45c3cf0e2242a533657f4f535d9b6a7447a79
- https://git.kernel.org/stable/c/9781e98a97110f5e76999058368b4be76a788484
- https://git.kernel.org/stable/c/9dc16be373b382ddd4c274052a6e870a95e76c01
- https://git.kernel.org/stable/c/c3aaec463a632cf4187dc017e421bfa69d7834a9
- https://git.kernel.org/stable/c/d1a11bbdbb5ea9f172019c5a4a3e9d8eabd72179
Modified: 2025-11-10
CVE-2023-53139
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause out-of-bounds write in device_property_read_u8_array later.
- https://git.kernel.org/stable/c/0a3664a1058d4b2b1ea2112cc275ca47fba7fc08
- https://git.kernel.org/stable/c/11f180a5d62a51b484e9648f9b310e1bd50b1a57
- https://git.kernel.org/stable/c/27824b2f98818215adc9661e563252c48dab1a13
- https://git.kernel.org/stable/c/4357bbb921fe9e81d0fd9f70d669d1f177d8380e
- https://git.kernel.org/stable/c/80be62358fa5507cefbaa067c7e6648401f2c3da
- https://git.kernel.org/stable/c/98f49e693e02c1dafd5786be3468657840dd6f06
- https://git.kernel.org/stable/c/ad11b872bc9b5d27e56183c6b01f9218c85395d2
- https://git.kernel.org/stable/c/ce93f1afc05941a572f5a69e2ed4012af905a693
Modified: 2025-11-10
CVE-2023-53140
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Remove the /proc/scsi/${proc_name} directory earlier Remove the /proc/scsi/${proc_name} directory earlier to fix a race condition between unloading and reloading kernel modules. This fixes a bug introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core"). Fix the following kernel warning: proc_dir_entry 'scsi/scsi_debug' already registered WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0 Call Trace: proc_mkdir+0xb5/0xe0 scsi_proc_hostdir_add+0xb5/0x170 scsi_host_alloc+0x683/0x6c0 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug] really_probe+0x159/0x540 __driver_probe_device+0xdc/0x230 driver_probe_device+0x4f/0x120 __device_attach_driver+0xef/0x180 bus_for_each_drv+0xe5/0x130 __device_attach+0x127/0x290 device_initial_probe+0x17/0x20 bus_probe_device+0x110/0x130 device_add+0x673/0xc80 device_register+0x1e/0x30 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug] scsi_debug_init+0x64f/0x1000 [scsi_debug] do_one_initcall+0xd7/0x470 do_init_module+0xe7/0x330 load_module+0x122a/0x12c0 __do_sys_finit_module+0x124/0x1a0 __x64_sys_finit_module+0x46/0x50 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0
- https://git.kernel.org/stable/c/13daafe1e209b03e9bda16ff2bd2b2da145a139b
- https://git.kernel.org/stable/c/17e98a5ede81b7696bec421f7afa2dfe467f5e6b
- https://git.kernel.org/stable/c/1ec363599f8346d5a8d08c71a0d9860d6c420ec0
- https://git.kernel.org/stable/c/6b223e32d66ca9db1f252f433514783d8b22a8e1
- https://git.kernel.org/stable/c/891a3cba425cf483d96facca55aebd6ff1da4338
- https://git.kernel.org/stable/c/e471e928de97b00f297ad1015cc14f9459765713
- https://git.kernel.org/stable/c/fc663711b94468f4e1427ebe289c9f05669699c9
Modified: 2025-11-10
CVE-2023-53141
In the Linux kernel, the following vulnerability has been resolved:
ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()
ila_xlat_nl_cmd_get_mapping() generates an empty skb,
triggerring a recent sanity check [1].
Instead, return an error code, so that user space
can get it.
[1]
skb_assert_len
WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]
WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
Modules linked in:
CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : skb_assert_len include/linux/skbuff.h:2527 [inline]
pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
lr : skb_assert_len include/linux/skbuff.h:2527 [inline]
lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
sp : ffff80001e0d6c40
x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0
x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00
x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10
x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0
x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001
x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600
x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001
x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000e
Call trace:
skb_assert_len include/linux/skbuff.h:2527 [inline]
__dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156
dev_queue_xmit include/linux/netdevice.h:3033 [inline]
__netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]
__netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325
netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338
__netlink_sendskb net/netlink/af_netlink.c:1283 [inline]
netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292
netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380
nlmsg_unicast include/net/netlink.h:1099 [inline]
genlmsg_unicast include/net/genetlink.h:433 [inline]
genlmsg_reply include/net/genetlink.h:443 [inline]
ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493
genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]
genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065
netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574
genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0x558/0x844 net/socket.c:2479
___sys_sendmsg net/socket.c:2533 [inline]
__sys_sendmsg+0x26c/0x33c net/socket.c:2562
__do_sys_sendmsg net/socket.c:2571 [inline]
__se_sys_sendmsg net/socket.c:2569 [inline]
__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52
el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193
el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637
el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
irq event stamp: 136484
hardirqs last enabled at (136483): [
- https://git.kernel.org/stable/c/25b54f247ea060aeb85ec88a82c75060fca03521
- https://git.kernel.org/stable/c/42d9ed4e5dc5f87fbd67c232e2e4a9b88ceeb47f
- https://git.kernel.org/stable/c/60fe7cb483c8c5dcadaeeac867251d6e59c7badc
- https://git.kernel.org/stable/c/693aa2c0d9b6d5b1f2745d31b6e70d09dbbaf06e
- https://git.kernel.org/stable/c/783f218940b3c7b872e4111d0145000f26ecbdf6
- https://git.kernel.org/stable/c/91aceb3844d4aec555c7f423f9fd843eff5835e9
- https://git.kernel.org/stable/c/b26bc5861505f04dea933ca3e522772b20fa086f
- https://git.kernel.org/stable/c/c631e52aea0fc8d4deea06e439f5810a8b40ad0f
Modified: 2025-11-10
CVE-2023-53143
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix another off-by-one fsmap error on 1k block filesystems
Apparently syzbot figured out that issuing this FSMAP call:
struct fsmap_head cmd = {
.fmh_count = ...;
.fmh_keys = {
{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
{ .fmr_device = /* ext4 dev */, .fmr_physical = 0, },
},
...
};
ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd);
Produces this crash if the underlying filesystem is a 1k-block ext4
filesystem:
kernel BUG at fs/ext4/ext4.h:3331!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4]
RSP: 0018:ffffc90007c03998 EFLAGS: 00010246
RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000
RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11
RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400
R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001
R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398
FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0
Call Trace:
- https://git.kernel.org/stable/c/15ebade3266b300da9cd1edce4004fe8fd6a2b88
- https://git.kernel.org/stable/c/1d2366624b4c19a2ba6baf67fe57f4a1b0f67c05
- https://git.kernel.org/stable/c/a70b49dc7eee5dbe3775a650ce598e3557ff5475
- https://git.kernel.org/stable/c/c24f838493792b5e78a3596b4ca96375aa0af4c2
- https://git.kernel.org/stable/c/c5d7c31e17224d847a330180ec1b03bf390632b2
- https://git.kernel.org/stable/c/c993799baf9c5861f8df91beb80e1611b12efcbd
- https://git.kernel.org/stable/c/eb3a695aa71a514f2e7f5778e05faba3733b70a0
- https://git.kernel.org/stable/c/f16054ac1774915160ca4e1c73ff7a269465a1b9
Modified: 2025-11-24
CVE-2023-53153
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Fix use after free for wext Key information in wext.connect is not reset on (re)connect and can hold data from a previous connection. Reset key data to avoid that drivers or mac80211 incorrectly detect a WEP connection request and access the freed or already reused memory. Additionally optimize cfg80211_sme_connect() and avoid an useless schedule of conn_work.
- https://git.kernel.org/stable/c/015b8cc5e7c4d7bb671f1984d7b7338c310b185b
- https://git.kernel.org/stable/c/22dfb21bf1cd876616d45cda1bc6daa89eec6747
- https://git.kernel.org/stable/c/2cfe78619b0de6d2da773978bc2d22797212eaa7
- https://git.kernel.org/stable/c/66af4a2ab1d65d556d638cb9555a3b823c2557a9
- https://git.kernel.org/stable/c/6f1959c17d4cb5b74af6fc31dc787e1dc3e4f6e2
- https://git.kernel.org/stable/c/a2a92b3e9d8e03ee3f9ee407fc46a9b4bd02d8b6
- https://git.kernel.org/stable/c/f4b6a138efb8a32507b8946104e32cb926308da7
- https://git.kernel.org/stable/c/fd081afd21eb35b968b0330700c43ec94986e1c4
Modified: 2025-11-24
CVE-2023-53164
In the Linux kernel, the following vulnerability has been resolved: irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/02298b7bae12936ca313975b02e7f98b06670d37
- https://git.kernel.org/stable/c/07fceab32096c1290b491f2fcaace03f78e2db37
- https://git.kernel.org/stable/c/4ae40c20f1519e1767ba01609abc7e8d6485fc0c
- https://git.kernel.org/stable/c/856fc2195494d1175ada0f1f46f92c5b28ce12eb
- https://git.kernel.org/stable/c/a0d91a48e1a020fb636f0fcaf44672f123bb0799
- https://git.kernel.org/stable/c/df8d3536b660c6c6f6b25fa8b157e9b38ad78142
Modified: 2025-12-02
CVE-2023-53171
In the Linux kernel, the following vulnerability has been resolved: vfio/type1: prevent underflow of locked_vm via exec() When a vfio container is preserved across exec, the task does not change, but it gets a new mm with locked_vm=0, and loses the count from existing dma mappings. If the user later unmaps a dma mapping, locked_vm underflows to a large unsigned value, and a subsequent dma map request fails with ENOMEM in __account_locked_vm. To avoid underflow, grab and save the mm at the time a dma is mapped. Use that mm when adjusting locked_vm, rather than re-acquiring the saved task's mm, which may have changed. If the saved mm is dead, do nothing. locked_vm is incremented for existing mappings in a subsequent patch.
- https://git.kernel.org/stable/c/046eca5018f8a5dd1dc2cedf87fb5843b9ea3026
- https://git.kernel.org/stable/c/5a271242716846cc016736fb76be2b40ee49b0c3
- https://git.kernel.org/stable/c/a6b2aabe664098d5cf877ae0fd96459464a30e17
- https://git.kernel.org/stable/c/b0790dff0760b7734cf0961f497ad64628ca550b
- https://git.kernel.org/stable/c/eafb81c50da899dd80b340c841277acc4a1945b7
Modified: 2025-12-02
CVE-2023-53191
In the Linux kernel, the following vulnerability has been resolved: irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/071d068b89e95d1b078aa6bbcb9d0961b77d6aa1
- https://git.kernel.org/stable/c/5fbf2cc39b62a4afe44f3d42ee3dcf8f012c1926
- https://git.kernel.org/stable/c/65e30bd1310d90b794c377bf405394157854aa30
- https://git.kernel.org/stable/c/9e79ac4f70fd51243e1c6108d4b0baf16cfde99c
- https://git.kernel.org/stable/c/c9aaf4efe1f02b2fef21a69fb3652f5ad12a5710
- https://git.kernel.org/stable/c/d6c66c46889752fa4962c6388516f7ab66a8d6a1
- https://git.kernel.org/stable/c/eef04516f0c317ce80502c1d6b0d06235a87cd8f
- https://git.kernel.org/stable/c/eef09f786df4b34b97557929287c4e5a83bbf09b
Modified: 2025-12-03
CVE-2023-53199
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: clean up skbs if ath9k_hif_usb_rx_stream() fails Syzkaller detected a memory leak of skbs in ath9k_hif_usb_rx_stream(). While processing skbs in ath9k_hif_usb_rx_stream(), the already allocated skbs in skb_pool are not freed if ath9k_hif_usb_rx_stream() fails. If we have an incorrect pkt_len or pkt_tag, the input skb is considered invalid and dropped. All the associated packets already in skb_pool should be dropped and freed. Added a comment describing this issue. The patch also makes remain_skb NULL after being processed so that it cannot be referenced after potential free. The initialization of hif_dev fields which are associated with remain_skb (rx_remain_len, rx_transfer_len and rx_pad_len) is moved after a new remain_skb is allocated. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
- https://git.kernel.org/stable/c/0af54343a76263a12dbae7fafb64eb47c4a6ad38
- https://git.kernel.org/stable/c/3fc6401fafde11712a83089fa2cc874cfd10e2cd
- https://git.kernel.org/stable/c/61490d2710277e8a55009b7682456ae22f8087cf
- https://git.kernel.org/stable/c/9acdec72787af1bc8ed92711b52118c8e3e638a2
- https://git.kernel.org/stable/c/c766e37fccd5a5c5059be7efcd9618bf8a2c17c3
- https://git.kernel.org/stable/c/cd8316767099920a5d41feed1afab0c482a43e9f
- https://git.kernel.org/stable/c/f26dd69f61eff2eedf5df2d199bdd23108309947
Modified: 2026-01-14
CVE-2023-53216
In the Linux kernel, the following vulnerability has been resolved: arm64: efi: Make efi_rt_lock a raw_spinlock Running a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs the following: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by kworker/u320:0/9: #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41) #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) Preemption disabled at: efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248) CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G W 6.2.0-rc3-rt1 Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18 Workqueue: efi_rts_wq efi_call_rts Call trace: dump_backtrace (arch/arm64/kernel/stacktrace.c:158) show_stack (arch/arm64/kernel/stacktrace.c:165) dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) dump_stack (lib/dump_stack.c:114) __might_resched (kernel/sched/core.c:10134) rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4)) efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101) [...] This seems to come from commit ff7a167961d1 ("arm64: efi: Execute runtime services from a dedicated stack") which adds a spinlock. This spinlock is taken through: efi_call_rts() \-efi_call_virt() \-efi_call_virt_pointer() \-arch_efi_call_virt_setup() Make 'efi_rt_lock' a raw_spinlock to avoid being preempted. [ardb: The EFI runtime services are called with a different set of translation tables, and are permitted to use the SIMD registers. The context switch code preserves/restores neither, and so EFI calls must be made with preemption disabled, rather than only disabling migration.]
- https://git.kernel.org/stable/c/030b1c4217a4f504c7d0795a2bd86b7181e56f11
- https://git.kernel.org/stable/c/0e68b5517d3767562889f1d83fdb828c26adb24f
- https://git.kernel.org/stable/c/4e8f7d998b582a99aadedd07ae6086e99b89c97a
- https://git.kernel.org/stable/c/6a72729ed6accc86dad5522895e8fa2f96642a2c
- https://git.kernel.org/stable/c/8b38969fa01662ec539a0d08a8ea5ec6f31fa4ed
Modified: 2026-01-14
CVE-2023-53223
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: Add missing check for alloc_ordered_workqueue Add check for the return value of alloc_ordered_workqueue as it may return NULL pointer and cause NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/517646/
- https://git.kernel.org/stable/c/115906ca7b535afb1fe7b5406c566ccd3873f82b
- https://git.kernel.org/stable/c/25a6499b1a53d854eda2b161b5c8a20296515dbe
- https://git.kernel.org/stable/c/3a9a4a9725c60f04326b5019a52ce15aee808506
- https://git.kernel.org/stable/c/3e18f157faeeb59034404569e8e07cbe1c0030a7
- https://git.kernel.org/stable/c/540c66180afd59309a442d3bf1f2393464c8b4c5
- https://git.kernel.org/stable/c/5dfe7a5386fde5a656ca06602b31bf50e26954cd
- https://git.kernel.org/stable/c/759ea5677c362fb1e3edc667260ba9f409dc931d
- https://git.kernel.org/stable/c/9257974858ee847b2e1fd552691b8ba5c2fc1c7b
Modified: 2026-01-14
CVE-2023-53233
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix deadlock triggered by cancel_delayed_work_syn() The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock: 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0 __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20 __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr ---truncated---
- https://git.kernel.org/stable/c/13085e1b5cab8ad802904d72e6a6dae85ae0cd20
- https://git.kernel.org/stable/c/3517584cf1b35bd02f4a90267ddf9dcf17bd9c87
- https://git.kernel.org/stable/c/9708efad9ba5095b9bb7916e11a135b3bd66c071
- https://git.kernel.org/stable/c/b615238e5bc01e13dc0610febddc1ca99bab1df6
- https://git.kernel.org/stable/c/c9ca2257150272df1b8d9ebe5059197ffea6e913
Modified: 2026-01-14
CVE-2023-53234
In the Linux kernel, the following vulnerability has been resolved: watchdog: Fix kmemleak in watchdog_cdev_register kmemleak reports memory leaks in watchdog_dev_register, as follows: unreferenced object 0xffff888116233000 (size 2048): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 32 bytes): 80 fa b9 05 81 88 ff ff 08 30 23 16 81 88 ff ff .........0#..... 08 30 23 16 81 88 ff ff 00 00 00 00 00 00 00 00 .0#............. backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<000000006a389304>] kmalloc_trace+0x21/0x110 [<000000008d640eea>] watchdog_dev_register+0x4e/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... unreferenced object 0xffff888105b9fa80 (size 16): comm ""modprobe"", pid 28147, jiffies 4353426116 (age 61.741s) hex dump (first 16 bytes): 77 61 74 63 68 64 6f 67 31 00 b9 05 81 88 ff ff watchdog1....... backtrace: [<000000007f001ffd>] __kmem_cache_alloc_node+0x157/0x220 [<00000000486ab89b>] __kmalloc_node_track_caller+0x44/0x1b0 [<000000005a39aab0>] kvasprintf+0xb5/0x140 [<0000000024806f85>] kvasprintf_const+0x55/0x180 [<000000009276cb7f>] kobject_set_name_vargs+0x56/0x150 [<00000000a92e820b>] dev_set_name+0xab/0xe0 [<00000000cec812c6>] watchdog_dev_register+0x285/0x780 [watchdog] [<0000000053c9f248>] __watchdog_register_device+0x4f0/0x680 [watchdog] [<00000000b2979824>] watchdog_register_device+0xd2/0x110 [watchdog] [<000000001f730178>] 0xffffffffc10880ae [<000000007a1a8bcc>] do_one_initcall+0xcb/0x4d0 [<00000000b98be325>] do_init_module+0x1ca/0x5f0 [<0000000046d08e7c>] load_module+0x6133/0x70f0 ... The reason is that put_device is not be called if cdev_device_add fails and wdd->id != 0. watchdog_cdev_register wd_data = kzalloc [1] err = dev_set_name [2] .. err = cdev_device_add if (err) { if (wdd->id == 0) { // wdd->id != 0 .. } return err; // [1],[2] would be leaked To fix it, call put_device in all wdd->id cases.
- https://git.kernel.org/stable/c/13721a2ac66b246f5802ba1b75ad8637e53eeecc
- https://git.kernel.org/stable/c/23cc41c3f19c4d858c3708f1c0a06e94958e6c3b
- https://git.kernel.org/stable/c/50808d034e199fe3ff7a9d2068a4eebeb6b4098a
- https://git.kernel.org/stable/c/59e391b3fc507a15b7e8e9d9f4de87cae177c366
- https://git.kernel.org/stable/c/8c1655600f4f2839fb844fe8c70b2b65fadc7a56
- https://git.kernel.org/stable/c/ac099d94e0480c937aa9172ab64074981ca1a4d3
- https://git.kernel.org/stable/c/bf26b0e430ce34261f45959989edaf680b64d538
- https://git.kernel.org/stable/c/c5a21a5501508ae3afa2fe6d5a3e74a37fa48df3
Modified: 2026-01-14
CVE-2023-53239
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Add check for kzalloc As kzalloc may fail and return NULL pointer, it should be better to check the return value in order to avoid the NULL pointer dereference. Patchwork: https://patchwork.freedesktop.org/patch/514154/
- https://git.kernel.org/stable/c/13fcfcb2a9a4787fe4e49841d728f6f2e9fa6911
- https://git.kernel.org/stable/c/37ff771ed008b9cbffd0eab77985968364694ce3
- https://git.kernel.org/stable/c/3975ea6eaffe26aec634b5c473e51dc76e73af62
- https://git.kernel.org/stable/c/49907c8873826ee771ba0ca1629e809c6479f617
- https://git.kernel.org/stable/c/82943a0730e00c14b03e25a4b2a1a9477ae89d7b
- https://git.kernel.org/stable/c/bc579a2ee8b2e20c152b24b437d094832d8c9c9e
Modified: 2026-01-14
CVE-2023-53242
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/hisi: Drop second sensor hi3660 The commit 74c8e6bffbe1 ("driver core: Add __alloc_size hint to devm allocators") exposes a panic "BRK handler: Fatal exception" on the hi3660_thermal_probe funciton. This is because the function allocates memory for only one sensors array entry, but tries to fill up a second one. Fix this by removing the unneeded second access.
- https://git.kernel.org/stable/c/15cc25829a97c3957e520e971868aacc84341317
- https://git.kernel.org/stable/c/3cf2181e438f43ed24e12424fe36d156cca233b9
- https://git.kernel.org/stable/c/68e675a9b69cfc34dd915d91a4650e3ee53421f4
- https://git.kernel.org/stable/c/9f6756cd09889c7201ee31e6f76fbd914fb0b80d
- https://git.kernel.org/stable/c/e02bc492883abf751fd1a8d89fc025fbce6744c6
- https://git.kernel.org/stable/c/f5aaf140ab1c02889c088e1b1098adad600541af
Modified: 2026-01-14
CVE-2023-53265
In the Linux kernel, the following vulnerability has been resolved:
ubi: ensure that VID header offset + VID header size <= alloc, size
Ensure that the VID header offset + VID header size does not exceed
the allocated area to avoid slab OOB.
BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197
Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555
CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W
6.0.0-1868 #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29
04/01/2014
Call Trace:
- https://git.kernel.org/stable/c/1b42b1a36fc946f0d7088425b90d491b4257ca3e
- https://git.kernel.org/stable/c/61aeba0e4b4124cfe3c5427feaf29c626dfa89e5
- https://git.kernel.org/stable/c/61e04db3bec87f7dd10074296deb7d083e2ccade
- https://git.kernel.org/stable/c/701bb3ed5a88a73ebbe1266895bdeff065226dca
- https://git.kernel.org/stable/c/771e207a839a29ba943e89f473b0fecd16089e2e
- https://git.kernel.org/stable/c/846bfba34175c23b13cc2023c2d67b96e8c14c43
- https://git.kernel.org/stable/c/e1b73fe4f4c6bb80755eb4bf4b867a8fd8b1a7fe
- https://git.kernel.org/stable/c/f7adb740f97b6fa84e658892dcb08e37a31a4e77
Modified: 2026-01-14
CVE-2023-53271
In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()
There is a memory leaks problem reported by kmemleak:
unreferenced object 0xffff888102007a00 (size 128):
comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s)
hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
backtrace:
[
- https://git.kernel.org/stable/c/07b60f7452d2fa731737552937cb81821919f874
- https://git.kernel.org/stable/c/09780a44093b53f9cbca76246af2e4ff0884e512
- https://git.kernel.org/stable/c/1e591ea072df7211f64542a09482b5f81cb3ad27
- https://git.kernel.org/stable/c/26ec2d66aecab8ff997b912c20247fedba4f5740
- https://git.kernel.org/stable/c/27b760b81951d8d5e5c952a696af8574052b0709
- https://git.kernel.org/stable/c/31d60afe2cc2b712dbefcaab6b7d6a47036f844e
- https://git.kernel.org/stable/c/5c0c81a313492b83bd0c038b8839b0e04eb87563
- https://git.kernel.org/stable/c/95a72417dd13ebcdcb1bd0c5d4d15f7c5bfbb288
Modified: 2026-01-14
CVE-2023-53277
In the Linux kernel, the following vulnerability has been resolved: wifi: iwl3945: Add missing check for create_singlethread_workqueue Add the check for the return value of the create_singlethread_workqueue in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/17e07d6587c55015956862ef3b101fd45fa49fbc
- https://git.kernel.org/stable/c/1fdeb8b9f29dfd64805bb49475ac7566a3cb06cb
- https://git.kernel.org/stable/c/2f80b3ff92514ebd227e5c55d3d1e480401b02b7
- https://git.kernel.org/stable/c/34f611204ae589bd5c494b10b41fb13436bd3c3f
- https://git.kernel.org/stable/c/3ae2fc4de12686f3fe695824169c1272c9f798f7
- https://git.kernel.org/stable/c/505c74c4c0b1c5bcaa98a93b3087c268156070f1
- https://git.kernel.org/stable/c/7e594abc0424e4f8c2385f11aefeaadcfc507aa5
Modified: 2026-01-14
CVE-2023-53295
In the Linux kernel, the following vulnerability has been resolved: udf: Do not update file length for failed writes to inline files When write to inline file fails (or happens only partly), we still updated length of inline data as if the whole write succeeded. Fix the update of length of inline data to happen only if the write succeeds.
- https://git.kernel.org/stable/c/256fe4162f8b5a1625b8603ca5f7ff79725bfb47
- https://git.kernel.org/stable/c/5621f7a8139053d0c3c47fb68ee9f602139eb40a
- https://git.kernel.org/stable/c/5a6c373d761f55635e175fa2f407544bae8f583b
- https://git.kernel.org/stable/c/6837910aeb2c9101fc036dcd1b1f32615c20ec1a
- https://git.kernel.org/stable/c/6d18cedc1ef0caeb1567cab660079e48844ff6d6
- https://git.kernel.org/stable/c/7bd8d9e1cf5607ee14407f4060b9a1dbb3c42802
- https://git.kernel.org/stable/c/c5787d77a5c29fffd295d138bd118b334990a567
- https://git.kernel.org/stable/c/eb2133900cac2d2f78befd6be41666cf1a2315d9
Modified: 2026-01-14
CVE-2023-53298
In the Linux kernel, the following vulnerability has been resolved: nfc: fix memory leak of se_io context in nfc_genl_se_io The callback context for sending/receiving APDUs to/from the selected secure element is allocated inside nfc_genl_se_io and supposed to be eventually freed in se_io_cb callback function. However, there are several error paths where the bwi_timer is not charged to call se_io_cb later, and the cb_context is leaked. The patch proposes to free the cb_context explicitly on those error paths. At the moment we can't simply check 'dev->ops->se_io()' return value as it may be negative in both cases: when the timer was charged and was not.
- https://git.kernel.org/stable/c/25ff6f8a5a3b8dc48e8abda6f013e8cc4b14ffea
- https://git.kernel.org/stable/c/271eed1736426103335c5aac50f15b0f4d236bc0
- https://git.kernel.org/stable/c/5321da6d84b87a34eea441677d649c34bd854169
- https://git.kernel.org/stable/c/8978315cb4bf8878c9c8ec05dafd8f7ff539860d
- https://git.kernel.org/stable/c/af452e35b9e6a87cd49e54a7a3d60d934b194651
- https://git.kernel.org/stable/c/b2036a252381949d3b743a3de069324ae3028a57
- https://git.kernel.org/stable/c/ba98db08895748c12e5ded52cd1598dce2c79e55
- https://git.kernel.org/stable/c/c494365432dcdc549986f4d9af9eb6190cbdb153
Modified: 2026-01-14
CVE-2023-53302
In the Linux kernel, the following vulnerability has been resolved: wifi: iwl4965: Add missing check for create_singlethread_workqueue() Add the check for the return value of the create_singlethread_workqueue() in order to avoid NULL pointer dereference.
- https://git.kernel.org/stable/c/26e6775f75517ad6844fe5b79bc5f3fa8c22ee61
- https://git.kernel.org/stable/c/2f85c768bea2057e3299d19514da9e932c4f92d2
- https://git.kernel.org/stable/c/3185d6cfc59277a77bf311dce701b7e25193f66a
- https://git.kernel.org/stable/c/874a85051cc8df8c5b928d8ff172b342cdc5424b
- https://git.kernel.org/stable/c/878a7c8357764e08bc778bcb26127fc12a4b36b7
- https://git.kernel.org/stable/c/c002d2741400771171b68dde9af937a4dfa0d1b3
- https://git.kernel.org/stable/c/f15ef0ebcf56be1d4a3c9a7a80a1f1f82ab0eaad
Modified: 2026-01-14
CVE-2023-53307
In the Linux kernel, the following vulnerability has been resolved:
rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails
If getting an ID or setting up a work queue in rbd_dev_create() fails,
use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts
is triggered in do_rbd_add(). The root cause is that the ownership of
these structures is transfered to rbd_dev prematurely and they all end
up getting freed when rbd_dev_create() calls rbd_dev_free() prior to
returning to do_rbd_add().
Found by Linux Verification Center (linuxtesting.org) with SVACE, an
incomplete patch submitted by Natalia Petrova
- https://git.kernel.org/stable/c/71da2a151ed1adb0aea4252b16d81b53012e7afd
- https://git.kernel.org/stable/c/9787b328c42c13c4f31e7d5042c4e877e9344068
- https://git.kernel.org/stable/c/a73783e4e0c4d1507794da211eeca75498544dff
- https://git.kernel.org/stable/c/ae16346078b1189aee934afd872d9f3d0a682c33
- https://git.kernel.org/stable/c/cc8c0dd2984503ed09efa37bcafcef3d3da104e8
- https://git.kernel.org/stable/c/e3cbb4d60764295992c95344f2d779439e8b34ce
- https://git.kernel.org/stable/c/f7c4d9b133c7a04ca619355574e96b6abf209fba
- https://git.kernel.org/stable/c/faa7b683e436664fff5648426950718277831348
Modified: 2026-01-14
CVE-2023-53346
In the Linux kernel, the following vulnerability has been resolved: kernel/fail_function: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
- https://git.kernel.org/stable/c/29d53c4c5a6f6d2b93aaac95b65cb4c907faf2ff
- https://git.kernel.org/stable/c/2bb3669f576559db273efe49e0e69f82450efbca
- https://git.kernel.org/stable/c/94f68f3e059c478e240f65fcb64746fe371295df
- https://git.kernel.org/stable/c/bb99db06b8b6ce9351633fc61bec9919d8f6f52b
- https://git.kernel.org/stable/c/dd9981a11d74ff2eb253bb5c459876f8bd3c6c36
- https://git.kernel.org/stable/c/f6d3aee1c66358471275df9dddd480010f061b0e
Modified: 2026-01-14
CVE-2023-53349
In the Linux kernel, the following vulnerability has been resolved: media: ov2740: Fix memleak in ov2740_init_controls() There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock device: unreferenced object 0xffff8881090e19e0 (size 16): comm "51-i2c-ov2740", pid 278, jiffies 4294781584 (age 23.613s) hex dump (first 16 bytes): 00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|......uj..... backtrace: [<000000004e9fad8f>] __kmalloc_node+0x44/0x1b0 [<0000000039c802f4>] kvmalloc_node+0x34/0x180 [<000000009b8b5c63>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<0000000038644056>] ov2740_probe+0x37d/0x84f [ov2740] [<0000000092489f59>] i2c_device_probe+0x28d/0x680 [<000000001038babe>] really_probe+0x17c/0x3f0 [<0000000098c7af1c>] __driver_probe_device+0xe3/0x170 [<00000000e1b3dc24>] device_driver_attach+0x34/0x80 [<000000005a04a34d>] bind_store+0x10b/0x1a0 [<00000000ce25d4f2>] drv_attr_store+0x49/0x70 [<000000007d9f4e9a>] sysfs_kf_write+0x8c/0xb0 [<00000000be6cff0f>] kernfs_fop_write_iter+0x216/0x2e0 [<0000000031ddb40a>] vfs_write+0x658/0x810 [<0000000041beecdd>] ksys_write+0xd6/0x1b0 [<0000000023755840>] do_syscall_64+0x38/0x90 [<00000000b2cc2da2>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ov2740_init_controls() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak.
- https://git.kernel.org/stable/c/2d899592ed7829d0d5140853bac4d58742a6b8af
- https://git.kernel.org/stable/c/3969b2ebc66039306f505c7c630c5530800f83c0
- https://git.kernel.org/stable/c/7c405ee63447f14eefcfe12a18aa749abbd596ea
- https://git.kernel.org/stable/c/a163ee11345d8322321c28bd61631de32455b987
- https://git.kernel.org/stable/c/fc33380ae06f438b652f66b9370b543976ac8a03
Modified: 2026-01-14
CVE-2023-53373
In the Linux kernel, the following vulnerability has been resolved: crypto: seqiv - Handle EBUSY correctly As it is seqiv only handles the special return value of EINPROGERSS, which means that in all other cases it will free data related to the request. However, as the caller of seqiv may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.
- https://git.kernel.org/stable/c/1effbddaff60eeef8017c6dea1ee0ed970164d14
- https://git.kernel.org/stable/c/32e62025e5e52fbe4812ef044759de7010b15dbc
- https://git.kernel.org/stable/c/36ec108b7bd7e280edb22de028467bd09d644620
- https://git.kernel.org/stable/c/4d497e8b200a175094e0ac252ed878add39b8771
- https://git.kernel.org/stable/c/63551e4b7cbcd9914258827699eb2cb6ed6e4a16
- https://git.kernel.org/stable/c/9477db935eb690f697d9bcc4f608927841bc8b36
- https://git.kernel.org/stable/c/ae849d2f48019ff9c104e32bf588ccbfb200e971
- https://git.kernel.org/stable/c/cc4d0d4251748a8a68026938f4055d2ac47c5719
Modified: 2026-01-14
CVE-2023-53388
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Clean dangling pointer on bind error path mtk_drm_bind() can fail, in which case drm_dev_put() is called, destroying the drm_device object. However a pointer to it was still being held in the private object, and that pointer would be passed along to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that point, resulting in a panic. Clean the pointer when destroying the object in the error path to prevent this from happening.
- https://git.kernel.org/stable/c/36aa8c61af55675ed967900fbe5deb32d776f051
- https://git.kernel.org/stable/c/49cf87919daeeeeeb9e924c39bdd9203af434461
- https://git.kernel.org/stable/c/6a89ddee1686a8872384aaa9f0bcfa6b675acd86
- https://git.kernel.org/stable/c/7b551a501fa714890e55bae73efede1185728d72
- https://git.kernel.org/stable/c/9a48f99aa7bea15e0b1d8b0040c46b4792eddf3b
- https://git.kernel.org/stable/c/a161f1d92aabb3b8463f752bdc3474dc3a5ec0e5
- https://git.kernel.org/stable/c/f3887c771576c5d740c5c5b8bf654a8ab8020b7d
Modified: 2026-01-14
CVE-2023-53411
In the Linux kernel, the following vulnerability has been resolved: PM: EM: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
- https://git.kernel.org/stable/c/30fee10192e1239478a0987bc7ee445d5e980d46
- https://git.kernel.org/stable/c/5100c4efc30636aa48ac517dece3c3b7f84fe367
- https://git.kernel.org/stable/c/84e4d4885d0ae011860fb599d50d01b8fdca2b87
- https://git.kernel.org/stable/c/a0e8c13ccd6a9a636d27353da62c2410c4eca337
- https://git.kernel.org/stable/c/e974e8f1e37d22c0de07374f8ddc84073fef2f1d
Modified: 2026-01-14
CVE-2023-53423
In the Linux kernel, the following vulnerability has been resolved: objtool: Fix memory leak in create_static_call_sections() strdup() allocates memory for key_name. We need to release the memory in the following error paths. Add free() to avoid memory leak.
- https://git.kernel.org/stable/c/3a75866a5ceff5d4fdd5471e06c4c4d03e0298b3
- https://git.kernel.org/stable/c/3da73f102309fe29150e5c35acd20dd82063ff67
- https://git.kernel.org/stable/c/a1368eaea058e451d20ea99ca27e72d9df0d16dd
- https://git.kernel.org/stable/c/a8f63d747bf7c983882a5ea7456a5f84ad3acad5
- https://git.kernel.org/stable/c/d131718d9c45d559951f57c4b88209ca407433c4
Modified: 2026-01-14
CVE-2023-53427
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix warning and UAF when destroy the MR list
If the MR allocate failed, the MR recovery work not initialized
and list not cleared. Then will be warning and UAF when release
the MR:
WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110
CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82
RIP: 0010:__flush_work.isra.0+0xf7/0x110
Call Trace:
- https://git.kernel.org/stable/c/275a3d2b9408fc4895e342f772cab9a89960546e
- https://git.kernel.org/stable/c/2d0c4f5f618f58eba03385363717703bee873c64
- https://git.kernel.org/stable/c/3524d6da0fe88aee79f06be6572955d16ad76b39
- https://git.kernel.org/stable/c/3e161c2791f8e661eed24a2c624087084d910215
- https://git.kernel.org/stable/c/41832c62a75dad530dc5a2856c92ae5459d497e5
- https://git.kernel.org/stable/c/7cbd5bdb5bd4404a5da4309521134b42c65846c0
- https://git.kernel.org/stable/c/cfd85a0922c4696d768965e686ad805a58d9d834
Modified: 2026-01-14
CVE-2023-53437
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Handle cameras with invalid descriptors If the source entity does not contain any pads, do not create a link.
- https://git.kernel.org/stable/c/11196ee3916e50a5da3c1e6ecda19a02dca14ba3
- https://git.kernel.org/stable/c/1a76cfc388cf105d3e04ac592670a52a3864b1ba
- https://git.kernel.org/stable/c/2914259fcea23971c6fed8b2618d3a729a78c365
- https://git.kernel.org/stable/c/31a8d11d28b57656cebfbd4c0b8b76f6ad5b017d
- https://git.kernel.org/stable/c/41ddb251c68ac75c101d3a50a68c4629c9055e4c
- https://git.kernel.org/stable/c/4e4e6ca62e77539d4df8d13137e2683b10baddd9
- https://git.kernel.org/stable/c/c8f4a424af5879baefb0fb8a8a09b09ea1779483
- https://git.kernel.org/stable/c/d8aa2e1ae6426d7cbddf1735aed1a63ddf0e6909
Modified: 2026-01-14
CVE-2023-53443
In the Linux kernel, the following vulnerability has been resolved: mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get() as pm_runtime_get_sync() will increase the refcnt even when it returns an error.
- https://git.kernel.org/stable/c/4414a7ab80cebf715045e3c4d465feefbad21139
- https://git.kernel.org/stable/c/5a47bb71b1a94a279144fc3031d3c4591b38dd16
- https://git.kernel.org/stable/c/7195e642b49af60d4120fa1b45bd812ba528174f
- https://git.kernel.org/stable/c/754e81ff44061dda68da0fd4ef51bd1aa9fbf2cf
- https://git.kernel.org/stable/c/9893771097b22a8743a446e45994a177795ca4da
- https://git.kernel.org/stable/c/dc9437e9889c3dacf1f320e3cf08da74127573fe
Modified: 2026-01-16
CVE-2023-53449
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: Fix potential memleak in dasd_eckd_init() `dasd_reserve_req` is allocated before `dasd_vol_info_req`, and it also needs to be freed before the error returns, just like the other cases in this function.
- https://git.kernel.org/stable/c/460e9bed82e49db1b823dcb4e421783854d86c40
- https://git.kernel.org/stable/c/544a552be0869231799784279d52704c4d314d33
- https://git.kernel.org/stable/c/a50e28d433acf22258f9f34831057387f04ef074
- https://git.kernel.org/stable/c/aede5230d154b6b237985ec9df7ebbd1dce96810
- https://git.kernel.org/stable/c/ee986d80acdef710a886be404308188ea11000c8
- https://git.kernel.org/stable/c/ef3a7ffc0a6f833578bc8d1dcb79d0633c7e4ec3
Modified: 2026-01-16
CVE-2023-53453
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: free iio for atombios when driver shutdown Fix below kmemleak when unload radeon driver: unreferenced object 0xffff9f8608ede200 (size 512): comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s) hex dump (first 32 bytes): 00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500 [<00000000b6883cea>] atom_parse+0x117/0x230 [radeon] [<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon] [<00000000683f672e>] si_init+0x57/0x750 [radeon] [<00000000566cc31f>] radeon_device_init+0x559/0x9c0 [radeon] [<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon] [<00000000b5155064>] drm_dev_register+0xdd/0x1d0 [<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon] [<00000000e69ecca3>] pci_device_probe+0xe1/0x160 [<0000000019484b76>] really_probe.part.0+0xc1/0x2c0 [<000000003f2649da>] __driver_probe_device+0x96/0x130 [<00000000231c5bb1>] driver_probe_device+0x24/0xf0 [<0000000000a42377>] __driver_attach+0x77/0x190 [<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0 [<00000000633166d2>] driver_attach+0x1e/0x30 [<00000000313b05b8>] bus_add_driver+0x12c/0x1e0 iio was allocated in atom_index_iio() called by atom_parse(), but it doesn't got released when the dirver is shutdown. Fix this kmemleak by free it in radeon_atombios_fini().
- https://git.kernel.org/stable/c/107b8b542bb9dab4cbdc3276c85fbdd7f6782313
- https://git.kernel.org/stable/c/4773fadedca918faec443daaca5e4ea1c0ced144
- https://git.kernel.org/stable/c/9cdb96b55651c92fc949cfd54124406c3c912b6b
- https://git.kernel.org/stable/c/cb109cedbba11c33473e6780c256d8442a9e4460
- https://git.kernel.org/stable/c/cda2f7efbc2d857220dad32e315a54565b285c1c
- https://git.kernel.org/stable/c/ce9e9d3dcbb0d1551ffd1a7f16e7c051f3ba4140
- https://git.kernel.org/stable/c/e2791f2f4d1d804e45fa91b14295c326b64c65f1
- https://git.kernel.org/stable/c/f9f55fc64928b5e30d78f861c5fc76db9e769ebb
Modified: 2026-01-20
CVE-2023-53468
In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix memory leak in alloc_wbufs()
kmemleak reported a sequence of memory leaks, and show them as following:
unreferenced object 0xffff8881575f8400 (size 1024):
comm "mount", pid 19625, jiffies 4297119604 (age 20.383s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[
- https://git.kernel.org/stable/c/1f206002c6bc302bface871ef3f72c0bbcaa931c
- https://git.kernel.org/stable/c/26ec45f1c504e15268383019df139d7983f1e67f
- https://git.kernel.org/stable/c/3e29634eb56e6547272fe4e568f63421f8b3b9fa
- https://git.kernel.org/stable/c/4a1ff3c5d04b9079b4f768d9a71b51c4af578dd2
- https://git.kernel.org/stable/c/bf50229494f0443b3f08427d7df63e5a7e2a796a
- https://git.kernel.org/stable/c/e11f36d3bc4d23f620754a948fe7b82b63dcb185
Modified: 2026-01-20
CVE-2023-53477
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Add lwtunnel encap size of all siblings in nexthop calculation
In function rt6_nlmsg_size(), the length of nexthop is calculated
by multipling the nexthop length of fib6_info and the number of
siblings. However if the fib6_info has no lwtunnel but the siblings
have lwtunnels, the nexthop length is less than it should be, and
it will trigger a warning in inet6_rt_notify() as follows:
WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130
......
Call Trace:
- https://git.kernel.org/stable/c/4cc59f386991ec9374cb4bc83dbe1c0b5a95033f
- https://git.kernel.org/stable/c/aa75d826c221e8d48607aef33836cf872a159cf1
- https://git.kernel.org/stable/c/aba298b35619213ca787d08d472049627d8cd012
- https://git.kernel.org/stable/c/da26369377f0b671c14692e2d65ceb38131053e1
- https://git.kernel.org/stable/c/dcdddb5f490890d058ea1f194d661219e92fe88d
- https://git.kernel.org/stable/c/e11e4d524eba2d3c8fdf897d7ce3853f7573bae9
Modified: 2026-01-20
CVE-2023-53481
In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed Following process will trigger an infinite loop in ubi_wl_put_peb(): ubifs_bgt ubi_bgt ubifs_leb_unmap ubi_leb_unmap ubi_eba_unmap_leb ubi_wl_put_peb wear_leveling_worker e1 = rb_entry(rb_first(&ubi->used) e2 = get_peb_for_wl(ubi) ubi_io_read_vid_hdr // return err (flash fault) out_error: ubi->move_from = ubi->move_to = NULL wl_entry_destroy(ubi, e1) ubi->lookuptbl[e->pnum] = NULL retry: e = ubi->lookuptbl[pnum]; // return NULL if (e == ubi->move_from) { // NULL == NULL gets true goto retry; // infinite loop !!! $ top PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND 7676 root 20 0 0 0 0 R 100.0 0.0 ubifs_bgt0_0 Fix it by: 1) Letting ubi_wl_put_peb() returns directly if wearl leveling entry has been removed from 'ubi->lookuptbl'. 2) Using 'ubi->wl_lock' protecting wl entry deletion to preventing an use-after-free problem for wl entry in ubi_wl_put_peb(). Fetch a reproducer in [Link].
- https://git.kernel.org/stable/c/3afaaf6f5867dc4ad383808d4053f428ec7b867d
- https://git.kernel.org/stable/c/4d57a7333e26040f2b583983e1970d9d460e56b0
- https://git.kernel.org/stable/c/5af1c643184a5d09ff5b3f334077a4d0a163c677
- https://git.kernel.org/stable/c/8a18856e074479bd050b01e688c58defadce7ab0
- https://git.kernel.org/stable/c/b40d2fbf47af58377e898b5062077a47bb28a132
- https://git.kernel.org/stable/c/b5be23f6ae610bdb262160a1f294afee6d0e6a69
- https://git.kernel.org/stable/c/cc4bc532acda66189bddc03b3fe1ad689d9a48a2
- https://git.kernel.org/stable/c/f006f596fe851c3b6aae60b79f89f89f0e515d2f
Modified: 2026-01-16
CVE-2023-53494
In the Linux kernel, the following vulnerability has been resolved: crypto: xts - Handle EBUSY correctly As it is xts only handles the special return value of EINPROGRESS, which means that in all other cases it will free data related to the request. However, as the caller of xts may specify MAY_BACKLOG, we also need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-free.
- https://git.kernel.org/stable/c/51c082514c2dedf2711c99d93c196cc4eedceb40
- https://git.kernel.org/stable/c/57c3e1d63b63dc0841d41df729297cd7c1c35808
- https://git.kernel.org/stable/c/912eb10b65646ffd222256c78a1c566a3dac177d
- https://git.kernel.org/stable/c/92a07ba4f0af2cccdc2aa5ee32679c9c9714db90
- https://git.kernel.org/stable/c/d5870848879291700fe6c5257dcb48aadd10425c
Modified: 2026-01-23
CVE-2023-53506
In the Linux kernel, the following vulnerability has been resolved: udf: Do not bother merging very long extents When merging very long extents we try to push as much length as possible to the first extent. However this is unnecessarily complicated and not really worth the trouble. Furthermore there was a bug in the logic resulting in corrupting extents in the file as syzbot reproducer shows. So just don't bother with the merging of extents that are too long together.
- https://git.kernel.org/stable/c/3d20e3b768aff32112bdce8d3219d923ae75f9f1
- https://git.kernel.org/stable/c/53cafe1d6d8ef9f93318e5bfccc0d24f27d41ced
- https://git.kernel.org/stable/c/5d029799d381a9ee06209a222cae75f04c5d5304
- https://git.kernel.org/stable/c/7a965da79f2d22601f329cbfce588386b0847544
- https://git.kernel.org/stable/c/965982feb333aefa9256c0fe188b5f1b958aef63
- https://git.kernel.org/stable/c/9a8d602f0723586e668bae7e65c832ceb9bcc8bc
- https://git.kernel.org/stable/c/adac9ac6d2e04ea0782b91a00ba10706002f3ec4
- https://git.kernel.org/stable/c/d52252a1de4cf96a34f722b0cd8902d8ff78eb57
Modified: 2026-01-23
CVE-2023-53512
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix a memory leak Add a forgotten kfree().
- https://git.kernel.org/stable/c/28137ea3eb05a87329a7154a8ff410d9e8bcc0a5
- https://git.kernel.org/stable/c/30c7c72b6cf9d8c95f9b219c9d2e4e31b15bebe5
- https://git.kernel.org/stable/c/378cc0eec4aa546ce1ae17515e2dfab719d4fb1e
- https://git.kernel.org/stable/c/54dd96015e8d7a2a07359e2dfebf05b529d1780c
- https://git.kernel.org/stable/c/847cdbdcd5a24c1eec9595161a23b88fef91ff42
Modified: 2026-04-06
CVE-2023-53521
In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Fix slab-out-of-bounds in ses_intf_remove() A fix for: BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses] Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013 When edev->components is zero, accessing edev->component[0] members is wrong.
- https://git.kernel.org/stable/c/0595cdb587726b4f0fa780eb7462e3679d141e82
- https://git.kernel.org/stable/c/2fb1fa8425cce2dc4dce298275d22d7077694b73
- https://git.kernel.org/stable/c/40af9a6deed723485e05b7d3255a28750692e8db
- https://git.kernel.org/stable/c/578797f0c8cbc2e3ec5fc0dab87087b4c7073686
- https://git.kernel.org/stable/c/76f7050537476ac062ec23a544fbca8270f2d08b
- https://git.kernel.org/stable/c/82143faf01dda831b89eccef60c39ef8575ab08a
- https://git.kernel.org/stable/c/87e47be38d205df338c52ead43f23b2864567423
- https://git.kernel.org/stable/c/8f9542cad6c27297c8391de3a659f0b7948495d0
Modified: 2026-03-25
CVE-2023-53534
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: mtk_drm_crtc: Add checks for devm_kcalloc As the devm_kcalloc may return NULL, the return value needs to be checked to avoid NULL poineter dereference.
- https://git.kernel.org/stable/c/5bf1e3bd7da625ccf9a22c8cb7d65271e6e47f4c
- https://git.kernel.org/stable/c/62952905e195f7350bc230cf0960a74ddbceed5d
- https://git.kernel.org/stable/c/67ea657c7891c2f86a7750395640d9bdf2555926
- https://git.kernel.org/stable/c/7d569ae98ee5490585929be69fea68047679b7b2
- https://git.kernel.org/stable/c/b64b6dff15a38468b8cd33fc7864fa4e02b0933a
Modified: 2026-03-23
CVE-2023-53535
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: Add a check for oversized packets Occasionnaly we may get oversized packets from the hardware which exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early check which drops the packet to avoid invoking skb_over_panic() and move on to processing the next packet.
- https://git.kernel.org/stable/c/124ca24e0de958d2e20e0aa1e2434af7b72f8887
- https://git.kernel.org/stable/c/411317d2a4a7d6049d8efeef0d32ae43f8baefce
- https://git.kernel.org/stable/c/5c0862c2c962052ed5055220a00ac1cefb92fbcd
- https://git.kernel.org/stable/c/5f56767fb5f2df875b6553e08dbec6a45431c988
- https://git.kernel.org/stable/c/7cdb07e10c1258c08f31b24898930e4ece88d163
- https://git.kernel.org/stable/c/841881320562cbeac7046b537b91cd000480cea2
- https://git.kernel.org/stable/c/87363d1ab55e497702a9506ff423c422639c8a25
- https://git.kernel.org/stable/c/c34b1c0870323649d45c5074828d7f754dea2673
Modified: 2026-03-21
CVE-2023-53542
In the Linux kernel, the following vulnerability has been resolved: ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phy For some reason, the driver adding support for Exynos5420 MIPI phy back in 2016 wasn't used on Exynos5420, which caused a kernel panic. Add the proper compatible for it.
- https://git.kernel.org/stable/c/199624f3144d79fab1cff533ce6a4b82390520a3
- https://git.kernel.org/stable/c/29961ee63dd676cc67f7c00f76faa21e11f0d7c6
- https://git.kernel.org/stable/c/2e68a0f7bc576318a58335c31c542b358bc63f83
- https://git.kernel.org/stable/c/537bdfc1a67836fbd68bbe4210bc380f72cca47f
- https://git.kernel.org/stable/c/5d5aa219a790d61cad2c38e1aa32058f16ad2f0b
- https://git.kernel.org/stable/c/c075aa3467a799855a92289a3c619afc0a2ad193
- https://git.kernel.org/stable/c/f10001af0f7246cf3e43530d25f8d59a8db10df6
- https://git.kernel.org/stable/c/f2a6198f5ed7d6e4e06d87a4de007f2e45cc9583
Modified: 2026-03-21
CVE-2023-53564
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix defrag path triggering jbd2 ASSERT code path: ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERT crash stacks: PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2] Analysis This bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: call ocfs2_journal_access_di() before ocfs2_journal_dirty() in ocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is called by ocfs2_split_extent() during defragmenting. How to fix For ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller only needs to call journal start/stop pair. The fix method is to remove journal access/dirty from __ocfs2_move_extent(). The discussion for this patch: https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html
- https://git.kernel.org/stable/c/2c559b3ba8e0b9e3c4bb08159a28ccadc698410f
- https://git.kernel.org/stable/c/33665d1042666f2e5c736a3df1f453e31f030663
- https://git.kernel.org/stable/c/590507ebabd33cd93324c04f9a5538309a5ba934
- https://git.kernel.org/stable/c/5f43d34a51ed30e6a60f7e59d224a63014fe2cd5
- https://git.kernel.org/stable/c/60eed1e3d45045623e46944ebc7c42c30a4350f0
- https://git.kernel.org/stable/c/669134a66d37258e1c4a5cfbd5b82f547ae30fca
- https://git.kernel.org/stable/c/7f3b1c28e2908755fb248d3ee8ff56826f2387db
- https://git.kernel.org/stable/c/8163ea90d89b7012dd1fa4b28edf5db0c641eca7
Modified: 2026-03-23
CVE-2023-53582
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds Fix a stack-out-of-bounds read in brcmfmac that occurs when 'buf' that is not null-terminated is passed as an argument of strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with a CLM version string by memcpy() in brcmf_fil_iovar_data_get(). Ensure buf is null-terminated. Found by a modified version of syzkaller. [ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22 [ 33.021554][ T1896] ================================================================== [ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110 [ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896 [ 33.023852][ T1896] [ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 [ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event [ 33.026581][ T1896] Call Trace: [ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d [ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334 [ 33.028037][ T1896] ? strreplace+0xf2/0x110 [ 33.028403][ T1896] ? strreplace+0xf2/0x110 [ 33.028807][ T1896] kasan_report.cold+0x83/0xdf [ 33.029283][ T1896] ? strreplace+0xf2/0x110 [ 33.029666][ T1896] strreplace+0xf2/0x110 [ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40 [ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100 [ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0 [ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0 [ 33.032091][ T1896] ? find_held_lock+0x2d/0x110 [ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260 [ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0 [ 33.033582][ T1896] brcmf_attach+0x246/0xd40 [ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50 [ 33.034383][ T1896] ? kmemdup+0x30/0x40 [ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690 [ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 [ 33.035833][ T1896] usb_probe_interface+0x25f/0x710 [ 33.036315][ T1896] really_probe+0x1be/0xa90 [ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460 [ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0 [ 33.037383][ T1896] driver_probe_device+0x49/0x120 [ 33.037790][ T1896] __device_attach_driver+0x18a/0x250 [ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120 [ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0 [ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20 [ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120 [ 33.042330][ T1896] __device_attach+0x207/0x330 [ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0 [ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0 [ 33.043515][ T1896] bus_probe_device+0x1a2/0x260 [ 33.043914][ T1896] device_add+0xa61/0x1ce0 [ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660 [ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550 [ 33.045531][ T1896] usb_set_configuration+0x984/0x1770 [ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230 [ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90 [ 33.046931][ T1896] usb_probe_device+0x9c/0x220 [ 33.047434][ T1896] really_probe+0x1be/0xa90 [ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460 [ 33.048134][ T1896] driver_probe_device+0x49/0x120 [ 33.048516][ T1896] __device_attach_driver+0x18a/0x250 [ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120 ---truncated---
- https://git.kernel.org/stable/c/0ca2efea4f11c6255061e852ac188264c469c197
- https://git.kernel.org/stable/c/3b173b4ad9c001a555f44adc7836d6fe3afbe9ec
- https://git.kernel.org/stable/c/423a1297ea72bbddf64dbb0957f2879c0f2aa5d0
- https://git.kernel.org/stable/c/660145d708be52f946a82e5b633c020f58f996de
- https://git.kernel.org/stable/c/a0f0ce1c8ab9fe90618dc394e3d1568b5a9ac154
- https://git.kernel.org/stable/c/c02f733024d70105f22de8dd0a1252a0350cd516
- https://git.kernel.org/stable/c/ecb980dc79709c02f579a9c03cb92ccec189ab38
Modified: 2026-03-21
CVE-2023-53590
In the Linux kernel, the following vulnerability has been resolved:
sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop
With this refcnt added in sctp_stream_priorities, we don't need to
traverse all streams to check if the prio is used by other streams
when freeing one stream's prio in sctp_sched_prio_free_sid(). This
can avoid a nested loop (up to 65535 * 65535), which may cause a
stuck as Ying reported:
watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]
Call Trace:
- https://git.kernel.org/stable/c/03c3a5584a0a29821e59b7834635ce823050caaa
- https://git.kernel.org/stable/c/68ba44639537de6f91fe32783766322d41848127
- https://git.kernel.org/stable/c/6d529928ea212127851a2df8c40d822237ca946b
- https://git.kernel.org/stable/c/8ee401f89cdb10f39098c0656d695b2bc4052100
- https://git.kernel.org/stable/c/bf5540cbd20e2dae2c81ab9b31deef41ef147d0a
- https://git.kernel.org/stable/c/cec326443f01283ef68ea00c06ea073b1835a562
Modified: 2026-03-23
CVE-2023-53605
In the Linux kernel, the following vulnerability has been resolved: drm: amd: display: Fix memory leakage This commit fixes memory leakage in dc_construct_ctx() function.
- https://git.kernel.org/stable/c/1bdea8ee92a6abc650b2189fd5c53f36859baecb
- https://git.kernel.org/stable/c/6b8701be1f66064ca72733c5f6e13748cdbf8397
- https://git.kernel.org/stable/c/83ace0dd67ee386be1ddcf59dab49d6d9a54e62e
- https://git.kernel.org/stable/c/9ae15ebaefc4878d614f10cc56ea672f88cea582
- https://git.kernel.org/stable/c/d473c55ce1975c9e601c25293328a5039225d2b2
Modified: 2026-03-17
CVE-2023-53610
In the Linux kernel, the following vulnerability has been resolved: irqchip: Fix refcount leak in platform_irqchip_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak.
- https://git.kernel.org/stable/c/4401b485855700f296cae4d0db36a52948bff4fa
- https://git.kernel.org/stable/c/6caa5a2b78f5f53c433d3a3781e53325da22f0ac
- https://git.kernel.org/stable/c/b00baffcc2561374f8fe8af873d00531f19864eb
- https://git.kernel.org/stable/c/c32fb16331f612e66a7fa8930164e0dc15725b72
- https://git.kernel.org/stable/c/ea54b608d85b7536f92238f3259730fa06cb5d21
Modified: 2026-03-17
CVE-2023-53612
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Simplify platform device handling Coretemp's platform driver is unconventional. All the real work is done globally by the initcall and CPU hotplug notifiers, while the "driver" effectively just wraps an allocation and the registration of the hwmon interface in a long-winded round-trip through the driver core. The whole logic of dynamically creating and destroying platform devices to bring the interfaces up and down is error prone, since it assumes platform_device_add() will synchronously bind the driver and set drvdata before it returns, thus results in a NULL dereference if drivers_autoprobe is turned off for the platform bus. Furthermore, the unusual approach of doing that from within a CPU hotplug notifier, already commented in the code that it deadlocks suspend, also causes lockdep issues for other drivers or subsystems which may want to legitimately register a CPU hotplug notifier from a platform bus notifier. All of these issues can be solved by ripping this unusual behaviour out completely, simply tying the platform devices to the lifetime of the module itself, and directly managing the hwmon interfaces from the hotplug notifiers. There is a slight user-visible change in that /sys/bus/platform/drivers/coretemp will no longer appear, and /sys/devices/platform/coretemp.n will remain present if package n is hotplugged off, but hwmon users should really only be looking for the presence of the hwmon interfaces, whose behaviour remains unchanged.
- https://git.kernel.org/stable/c/4000384684f612b3645a944f6acde0e65ac370b8
- https://git.kernel.org/stable/c/52ea47a0ddfbc5fe05e873d3f5a59db4ba3e03fe
- https://git.kernel.org/stable/c/5735878a7b7db7e9ce731cb36cec298a9de67549
- https://git.kernel.org/stable/c/6d03bbff456befeccdd4d663177c4d6c75d0c4ff
- https://git.kernel.org/stable/c/8fcdbc4bc01365f4b10fed7db544a3149e3054fd
- https://git.kernel.org/stable/c/c57a8d14d7880521150ee801d53a0a64fdffd9c8
Modified: 2026-02-03
CVE-2023-53637
In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov772x: Fix memleak in ov772x_probe() A memory leak was reported when testing ov772x with bpf mock device: AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() are leaked.
- https://git.kernel.org/stable/c/1da495101ef7507eb4f4b1dbec2874d740eff251
- https://git.kernel.org/stable/c/448ce1cd50387b1345ec14eb191ef05f7afc2a26
- https://git.kernel.org/stable/c/7485edb2b6ca5960205c0a49bedfd09bba30e521
- https://git.kernel.org/stable/c/ac93f8ac66e60227bed42d5a023f0e6c15b52c0a
- https://git.kernel.org/stable/c/c86d760c1c6855a6131e78d0ddacc48c79324ac3
- https://git.kernel.org/stable/c/cc3b6011d7a9f149489eb9420c6305a779162c57
- https://git.kernel.org/stable/c/dfaafeb8e9537969e8dba75491f732478c7fa9d6
Modified: 2026-02-26
CVE-2023-53675
In the Linux kernel, the following vulnerability has been resolved: scsi: ses: Fix possible desc_ptr out-of-bounds accesses Sanitize possible desc_ptr out-of-bounds accesses in ses_enclosure_data_process().
- https://git.kernel.org/stable/c/414418abc19fa4ccf730d273061a426c07a061d6
- https://git.kernel.org/stable/c/4b8cae410472653a59e15af62c57c49b8e0a1201
- https://git.kernel.org/stable/c/584892fd29a41ef424a148118a3103b16b94fb8c
- https://git.kernel.org/stable/c/72021ae61a2bc6ca73cd593e255a10ed5f5dc5e7
- https://git.kernel.org/stable/c/79ec5dd5fb07ecaea2f978c2d7a9f2f3526e4d19
- https://git.kernel.org/stable/c/801ab13d50cf3d26170ee073ea8bb4eececb76ab
- https://git.kernel.org/stable/c/c315560e3ef77c1d822249f1743e647dc9c9912a
- https://git.kernel.org/stable/c/cffe09ca0555e235a42d6fa065e463c4b3d5b657
Modified: 2026-02-26
CVE-2023-53679
In the Linux kernel, the following vulnerability has been resolved: wifi: mt7601u: fix an integer underflow Fix an integer underflow that leads to a null pointer dereference in 'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet could be manipulated, which could trigger an integer underflow of 'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be bypassed, eventually leading to a dereference of the pointer 'p', which is a null pointer. Ensure that 'dma_len' is greater than 'min_seg_len'. Found by a modified version of syzkaller. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+ #139 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 RIP: 0010:skb_add_rx_frag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: mt7601u_rx_tasklet+0xc73/0x1270 ? mt7601u_submit_rx_buf.isra.0+0x510/0x510 ? tasklet_action_common.isra.0+0x79/0x2f0 tasklet_action_common.isra.0+0x206/0x2f0 __do_softirq+0x1b5/0x880 ? tasklet_unlock+0x30/0x30 run_ksoftirqd+0x26/0x50 smpboot_thread_fn+0x34f/0x7d0 ? smpboot_register_percpu_thread+0x370/0x370 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30 Modules linked in: 88XXau(O) 88x2bu(O) ---[ end trace 57f34f93b4da0f9b ]--- RIP: 0010:skb_add_rx_frag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554
- https://git.kernel.org/stable/c/1a1f43059afae5cc9409e0c3bc63bfc09bc8facb
- https://git.kernel.org/stable/c/47dc1f425af57b71111d7b01ebd24e04e8d967ef
- https://git.kernel.org/stable/c/61d0163e2be7a439cf6f82e9ad7de563ecf41e7a
- https://git.kernel.org/stable/c/67e4519afba215199b6dfa39ce5d7ea673ee4138
- https://git.kernel.org/stable/c/803f3176c5df3b5582c27ea690f204abb60b19b9
- https://git.kernel.org/stable/c/d0db59e2f718d1e2f1d2a2d8092168fdd2f3add0
