All errata/p10/ALT-PU-2024-14046-25
ALT-PU-2024-14046-25

Package update kernel-image-rpi-un in branch p10

Version6.6.56-alt1
Task#359697
Published2026-05-07
Max severityCRITICAL
Severity:

Closed issues (3013)

BDU:2022-07344
MEDIUM5.5

Уязвимость функции find_prog_by_sec_insn() (tools/lib/bpf/libbpf.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2022-12-22Modified: 2024-04-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-00381
MEDIUM5.7

Уязвимость функции rawv6_push_pending_frames() (net/ipv6/raw.c) службы обработки трафика ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-01-25Modified: 2024-09-30
CVSS 3.xMEDIUM 5.7
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-00748
MEDIUM5.5

Уязвимость видеодрайвера vivid ядра операционной системы Linux, позволяющая локальному нарушителю вызвать отказ в обслуживании

Published: 2023-02-15Modified: 2024-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-01125
MEDIUM6.8

Уязвимость компонента drivers/tty/vcc.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации

Published: 2023-03-07Modified: 2024-10-08
CVSS 3.xMEDIUM 6.8
CVSS:3.x/AV:P/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H
CVSS 2.0MEDIUM 5.6
CVSS:2.0/AV:L/AC:H/Au:N/C:N/I:C/A:C
References
BDU:2023-01206
MEDIUM6.8

Уязвимость функции asus_kbd_backlight_set() (drivers/hid/hid-asus.c) драйвера ASUS USB клавиатуры ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-03-15Modified: 2025-08-19
CVSS 3.xMEDIUM 6.8
CVSS:3.x/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2023-01215
MEDIUM5.5

Уязвимость функции memory_tier_init() (mm/memory-tiers.c) подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2023-03-15Modified: 2025-02-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-01276
MEDIUM6.5

Уязвимость функции smb2_is_status_io_timeout() компоненты SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-03-17Modified: 2025-08-19
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-01277
MEDIUM6.5

Уязвимость функции setup_async_work() (fs/ksmbd/smb2pdu.c) подсистеме SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-03-17Modified: 2024-11-11
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-01279
MEDIUM5.5

Уязвимость функции __sys_socket_file() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-03-17Modified: 2024-04-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-01282
MEDIUM5.5

Уязвимость функции az6027_i2c_xfer() (drivers/media/usb/dvb-usb/az6027.c) драйвера Azurewave DVB-S/S2 USB2.0 AZ6027 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-03-17Modified: 2024-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-01726
LOW3.3

Уязвимость функции kvm_vcpu_ioctl_x86_get_debugregs() (arch/x86/kvm/x86.c) подсистемы виртуализации KVM ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2023-03-28Modified: 2025-08-19
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2023-01778
MEDIUM5.3

Уязвимость функции hci_init_stage_sync() (net/bluetooth/hci_sync.c) ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию

Published: 2023-04-02Modified: 2024-04-03
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:N/A:N
References
BDU:2023-01800
MEDIUM5.5

Уязвимость функции sock_hash_delete_elem() в модуле net/core/sock_map.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-04-03Modified: 2025-01-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-01962
MEDIUM6.3

Уязвимость функции xgene_hwmon_remove (drivers/hwmon/xgene-hwmon.c) драйвера мониторинга оборудования xgene-hwmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании и раскрыть защищаемую информацию

Published: 2023-04-11Modified: 2025-08-19
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:N/A:C
References
BDU:2023-02090
MEDIUM6.4

Уязвимость функции da9150_charger_remove() драйвера drivers/power/supply/da9150-charger.c ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2023-04-17Modified: 2025-02-24
CVSS 3.xMEDIUM 6.4
CVSS:3.x/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:H/Au:N/C:C/I:C/A:C
References
BDU:2023-02115
MEDIUM5.6

Уязвимость функции prctl ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2023-04-18Modified: 2025-08-19
CVSS 3.xMEDIUM 5.6
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:N/A:N
References
BDU:2023-02118
MEDIUM6.8

Уязвимость подсистемы проверки разрешений Bluetooth ядра операционной системы Linux, позволяющая нарушителю выполнять произвольные команды

Published: 2023-04-19Modified: 2025-08-19
CVSS 3.xMEDIUM 6.8
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 6.7
CVSS:2.0/AV:A/AC:L/Au:S/C:P/I:P/A:C
References
BDU:2023-02162
MEDIUM6.5

Уязвимость функции nested_vmx_check_guest_state() модуля arch/x86/kvm/vmx/nested.c подсистемы виртуализации (KVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании гостевой операционной системы.

Published: 2023-04-20Modified: 2025-08-19
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-02166
MEDIUM4.7

Уязвимость функции xen_9pfs_front_remove() в модуле net/9p/trans_xen.c гипервизора Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-04-20Modified: 2025-01-29
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2023-02229
MEDIUM4.7

Уязвимость функции ndlc_remove() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-04-25Modified: 2024-09-30
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2023-02522
MEDIUM5.5

Уязвимость функции io_cqring_event_overflow() в модуле uring/msg_ring.c ядра операционной системы Linux, позволяющая нарушителю повысить привилегии или вызвать отказ в обслуживании

Published: 2023-05-15Modified: 2023-10-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-02524
MEDIUM6.7

Уязвимость функции slimpro_i2c_blkwr() в модуле drivers/i2c/busses/i2c-xgene-slimpro.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код

Published: 2023-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-02526
HIGH7.8

Уязвимость драйвера Infiniband ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии

Published: 2023-05-15Modified: 2024-11-11
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-02528
MEDIUM5.5

Уязвимость драйвере SCSI ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2023-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2023-02529
HIGH7.8

Уязвимость файловой системы XFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии

Published: 2023-05-15Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-02800
MEDIUM6.4

Уязвимость драйвера сетевого устройства Qualcomm ядра операционной системы Linux в функции emac_remove(), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2023-05-25Modified: 2025-02-27
CVSS 3.xMEDIUM 6.4
CVSS:3.x/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:H/Au:N/C:C/I:C/A:C
References
BDU:2023-02801
MEDIUM4.7

Уязвимость функции bq24190_remove() в модуле drivers/power/supply/bq24190_charger.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2023-05-25Modified: 2025-02-27
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2023-02997
MEDIUM5.5

Уязвимость драйвере файловой системы ext4 ядра операционной системы Linux в функции ext4_group_desc_csum(), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2023-06-05Modified: 2025-02-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-03110
MEDIUM5.5

Уязвимость функции hfsplus_put_super() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-06-09Modified: 2024-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-03169
MEDIUM4.4

Уязвимость функции gfs2_evict_inode() в модуле fs/gfs2/super.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-06-16Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-03170
HIGH7.8

Уязвимость функции fbcon_set_font() в модуле drivers/video/fbdev/core/fbcon.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-06-16Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-03435
HIGH7.0

Уязвимость функции ravb_remove() в модуле drivers/net/ethernet/renesas/ravb_main.c драйвера сетевых устройств Renesas ядра операционной системы Linux в функции ravb_remove(), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-06-26Modified: 2025-07-28
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2023-03494
MEDIUM4.7

Уязвимость функции dpu_crtc_atomic_check() в модуле drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c драйвера MSM DRM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-06-30Modified: 2025-01-29
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2023-03495
HIGH7.1

Уязвимость реализации файловой системы relayfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или раскрыть защищаемую информацию

Published: 2023-06-30Modified: 2025-08-19
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2023-03499
HIGH7.0

Уязвимость функции saa7134_finidev() в модуле drivers/media/pci/saa7134/saa7134-core.c драйвера Philips SAA7134 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2023-06-30Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-03500
HIGH7.0

Уязвимость функции dm1105_remove() в модуле drivers/media/pci/dm1105/dm1105.c драйвера TV Tuner на микросхеме DM1105 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2023-06-30Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2023-03641
MEDIUM4.7

Уязвимость функции ishtp_cl_get_dma_send_buf() драйвера Integrated Sensor Hub (ISH) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-07-11Modified: 2024-09-30
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.0
CVSS:2.0/AV:L/AC:H/Au:N/C:N/I:N/A:C
References
BDU:2023-03642
MEDIUM5.7

Уязвимость реализации протокола IPv6 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-07-11Modified: 2025-08-19
CVSS 3.xMEDIUM 5.7
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-03644
MEDIUM5.5

Уязвимость функции brcm_nvram_parse() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-07-11Modified: 2023-07-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-03725
MEDIUM6.5

Уязвимость функции dn_nsp_send() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-07-17Modified: 2024-11-11
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-03727
HIGH7.8

Уязвимость функции io_poll_update() в модуле io_uring/io_uring.c ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии

Published: 2023-07-18Modified: 2024-09-30
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-03782
HIGH7.1

Уязвимость функции vcs_read() в модуле drivers/tty/vt/vc_screen.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-07-19Modified: 2025-08-19
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2023-03783
MEDIUM4.6

Уязвимость функции read_descriptors() в модуле drivers/usb/core/sysfs.c драйвера USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-07-19Modified: 2025-08-19
CVSS 3.xMEDIUM 4.6
CVSS:3.x/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2023-03784
MEDIUM6.7

Уязвимость функции vmw_user_bo_lookup() в модуле drivers/gpu/drm/vmwgfx/vmwgfx_bo.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-07-19Modified: 2024-10-08
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.5
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:C/A:C
References
BDU:2023-03786
MEDIUM5.5

Уязвимость функции udf_close_lvid() в модуле fs/udf/super.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации

Published: 2023-07-19Modified: 2024-10-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-03958
MEDIUM5.5

Уязвимость функции set_con2fb_map() в модуле drivers/video/fbdev/core/fbcon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-07-24Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.0
CVSS:2.0/AV:L/AC:H/Au:N/C:N/I:N/A:C
References
BDU:2023-03960
HIGH7.8

Уязвимость функции u32_set_parms() в модуле net/sched/cls_u32.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность данных

Published: 2023-07-24Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-04069
MEDIUM5.3

Уязвимость драйвера vmwgfx ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию

Published: 2023-07-26Modified: 2024-12-04
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:N/A:N
References
BDU:2023-04271
MEDIUM6.4

Уязвимость функции nfc_llcp_find_local() в модуле net/nfc/llcp_core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-08-01Modified: 2024-11-07
CVSS 3.xMEDIUM 6.4
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 5.9
CVSS:2.0/AV:L/AC:H/Au:M/C:C/I:C/A:C
References
BDU:2023-04647
MEDIUM5.7

Уязвимость функции parse_usdt_arg() в модуле tools/lib/bpf/usdt.c компоненты BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-08-14Modified: 2024-04-27
CVSS 3.xMEDIUM 5.7
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-04654
MEDIUM5.5

Уязвимость функции do_submit_urb() в модуле drivers/media/usb/siano/smsusb.c драйвера цифрового ТВ siano ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-08-14Modified: 2024-11-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-04655
MEDIUM5.5

Уязвимость функции cxgb4_cleanup_tc_flower() в модуле drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c драйвера Chelsio cxgb4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-08-14Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-04656
MEDIUM5.5

Уязвимость функции cyttsp4_stop_wd_timer() в модуле drivers/input/touchscreen/cyttsp4_core.c драйвера сенсорного устройства Cypress TrueTouch Gen4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-08-14Modified: 2025-05-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-04659
MEDIUM5.5

Уязвимость функции tap_open() в модуле drivers/net/tap.c драйвере TUN/TAP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных или повысить свои привилегии

Published: 2023-08-14Modified: 2024-06-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:C/A:N
References
BDU:2023-04661
MEDIUM6.0

Уязвимость функции exfat_get_uniname_from_ext_entry() в модуле fs/exfat/dir.c файловой системе exFAT ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-08-14Modified: 2024-04-27
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
CVSS 2.0MEDIUM 5.9
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:C/A:N
References
BDU:2023-05142
HIGH7.1

Уязвимость функции nft_set_catchall_flush() в модуле net/netfilter/nf_tables_api.c компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2023-09-04Modified: 2025-02-06
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2023-05143
HIGH7.0

Уязвимость функции do_mbind() в модуле mm/mempolicy.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-09-04Modified: 2024-01-09
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2023-05481
HIGH7.0

Уязвимость компонента nf_tables операционной системы Linux, позволяющая нарушителю повысить свои привилегии

Published: 2023-09-12Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2023-05963
MEDIUM5.5

Уязвимость функции kmalloc_reserve() в модуле net/core/skbuff.c сетевой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-09-22Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-06159
MEDIUM4.7

Уязвимость функции __ip_set_put_netlink() в модуле net/netfilter/ipset/ip_set_core.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-09-29Modified: 2024-12-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2023-06161
MEDIUM6.5

Уязвимость функции rsvp_change() в модуле net/sched/cls_rsvp.h компонента net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-09-29Modified: 2025-08-19
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-06203
HIGH8.2

Уязвимость подсистемы eBPF ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии

Published: 2023-10-03Modified: 2024-09-12
CVSS 3.xHIGH 8.2
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2023-06271
MEDIUM6.0

Уязвимость функции u32_match_it подсистемы Netfilter ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации

Published: 2023-10-04Modified: 2025-08-19
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2023-06340
MEDIUM6.0

Уязвимость функции match_flags подсистемы Netfilter ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2023-10-05Modified: 2025-08-19
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2023-06420
MEDIUM5.5

Уязвимость функции ipv4_send_dest_unreach() в модуле net/ipv4/route.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-10-09Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-06613
MEDIUM6.0

Уязвимость функции nf_osf_match_one() подсистемы Netfilter ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании или получить несанкционированный доступ к защищаемой информации

Published: 2023-10-13Modified: 2025-08-19
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 5.9
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:N/A:C
References
BDU:2023-06751
MEDIUM4.4

Уязвимость функции xfrm_dump_sa() модуля net/xfrm/xfrm_user.c подсистемы XFRM ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2023-10-16Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2023-06996
MEDIUM6.3

Уязвимость функции extract_user_to_sg() в модуле lib/scatterlist.c библиотеки scatterlist ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации

Published: 2023-10-21Modified: 2024-01-09
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:C/A:C
References
BDU:2023-06997
MEDIUM5.5

Уязвимость функции ms_lib_process_bootblock() в модуле drivers/usb/storage/ene_ub6250.c драйвера ene_usb6250 кард-ридера ENE SD/MS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2023-10-21Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-06998
MEDIUM6.4

Уязвимость функции fill_kobj_path() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2023-10-21Modified: 2025-08-19
CVSS 3.xMEDIUM 6.4
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 5.9
CVSS:2.0/AV:L/AC:H/Au:M/C:C/I:C/A:C
References
BDU:2023-07236
HIGH7.0

Уязвимость ядра операционной системы Linux, вызванная ошибками синхронизации при использовании общего ресурса, позволяющая нарушителю выполнить произвольный код.

Published: 2023-10-28Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2023-07317
MEDIUM5.5

Уязвимость функции svm_set_x2apic_msr_interception() модуля arch/x86/kvm/svm/svm.c подсистемы KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-10-30Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-07513
MEDIUM4.7

Уязвимость функции io_uring_show_fdinfo() в модуле io_uring/fdinfo.c подсистемы io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-11-04Modified: 2024-11-11
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2023-07688
MEDIUM4.3

Уязвимость функции brcmf_cfg80211_detach() в модуле drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c драйвера беспроводной связи brcm80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-11-11Modified: 2024-12-24
CVSS 3.xMEDIUM 4.3
CVSS:3.x/AV:P/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-07947
MEDIUM5.5

Уязвимость функции lan78xx_disconnect (drivers/net/usb/lan78xx.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-11-18Modified: 2024-11-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-07977
HIGH7.5

Уязвимость функции qxl_gem_object_create_with_handle() модуля drivers/gpu/drm/qxl/qxl_gem.c драйвера QXL ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2023-11-21Modified: 2025-08-19
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 5.9
CVSS:2.0/AV:L/AC:H/Au:M/C:C/I:C/A:C
References
BDU:2023-08635
MEDIUM5.5

Уязвимость функции __io_uaddr_map() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-12-12Modified: 2025-01-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-08636
MEDIUM5.5

Уязвимость функции nft_dynset_init() (net/netfilter/nft_dynset.c) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2023-12-12Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2023-09114
HIGH7.0

Уязвимость функции gsm_cleanup_mux() драйвера N_GSM ядра операционных систем Linux, позволяющая нарушителю повысить свои привилегии

Published: 2023-12-26Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-00097
MEDIUM4.4

Уязвимость функции ctnetlink_create_conntrack() в модуле net/netfilter/nf_conntrack_netlink.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю с полномочиями CAP_NET_ADMIN вызвать отказ в обслуживании.

Published: 2024-01-09Modified: 2024-11-07
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2024-00101
HIGH7.0

Уязвимость функции rose_ioctl() в модуле net/rose/af_rose.c реализации протокола Amateur Radio X.25 PLP (Rose) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-01-09Modified: 2024-11-11
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-00102
HIGH7.0

Уязвимость функции atalk_ioctl() в модуле net/appletalk/ddp.c реализации протокола Appletalk в ядре операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-01-09Modified: 2024-11-11
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-00104
HIGH7.0

Уязвимость функции do_vcc_ioctl() в модуле net/atm/ioctl.c реализации сетевого протокола ATM (Asynchronous Transfer Mode) ядра операционной системы Linux , позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-01-09Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.1
CVSS:2.0/AV:N/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-00258
MEDIUM5.5

Уязвимость функции vhost_new_msg() в модуле drivers/vhost/vhost.c драйвера vhost ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2024-01-15Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2024-00636
MEDIUM5.5

Уязвимость функции tipc_crypto_key_revoke модуля net/tipc/crypto.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-01-24Modified: 2025-04-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-00673
MEDIUM5.5

Уязвимость функции sctp_auto_asconf_init (net/sctp/socket.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-01-25Modified: 2025-04-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-00776
HIGH7.1

Уязвимость функции __ext4_remount() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-01-30Modified: 2024-11-07
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-00836
HIGH7.8

Уязвимость функции smb2_get_data_area_len (fs/smb/server/smb2misc.c) файловой системы KSMBD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-01-31Modified: 2025-07-28
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-00837
HIGH7.0

Уязвимость функции drm_atomic_state_init (driver/gpu/drm/drm_atomic.c) ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код.

Published: 2024-01-31Modified: 2025-07-28
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-00865
MEDIUM5.5

Уязвимость функции send_acknowledge() в модуле net/nfc/nci/spi.c ядра операционной системы Linux в функции send_acknowledge(), позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2024-01-31Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-00866
HIGH7.8

Уязвимость функции amdgpu_cs_wait_all_fences() в модуле drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c драйвера amdgpu видеокарт AMD Radeon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-01-31Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-00896
HIGH7.8

Уязвимость функции raid5_cache_count() (drivers/md/raid5.c) драйвера RAID ядра операционной системы Linux, связанная с целочисленным переполнением, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-02-02Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-00985
HIGH7.8

Уязвимость функции hugetlbfs_fill_super системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или повысить свои привилегии

Published: 2024-02-06Modified: 2025-01-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-01034
HIGH7.8

Уязвимость модуля net/bluetooth/af_bluetooth.c драйвера bluetooth ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-02-07Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-01036
HIGH7.5

Уязвимость функции ip6_dst_gc() (net/ipv6/route.c) реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-02-07Modified: 2025-08-19
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2024-01189
MEDIUM5.3

Уязвимость функции exynos_drm_crtc_atomic_disable() в модуле drivers/gpu/drm/exynos/exynos_drm_crtc.c драйвера Samsung SoC Exynos ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-02-13Modified: 2024-02-26
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-01190
MEDIUM5.3

Уязвимость функции snd_hdac_regmap_sync() в модуле sound/hda/hdac_regmap.c драйвера High-Definition Audio (HDA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-02-13Modified: 2024-11-11
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-01192
MEDIUM4.7

Уязвимость функции lpfc_unregister_fcf_rescan() в модуле drivers/scsi/lpfc/lpfc_hbadisc.c подсистемы SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-02-13Modified: 2026-02-16
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-01193
MEDIUM6.8

Уязвимость функции conn_info_{min,max}_age_set() в модуле net/bluetooth/hci_debugfs.c. реализации протокола HCI драйвера bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации и вызвать отказ в обслуживании

Published: 2024-02-13Modified: 2025-08-19
CVSS 3.xMEDIUM 6.8
CVSS:3.x/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:A/AC:H/Au:N/C:C/I:C/A:C
References
BDU:2024-01194
MEDIUM5.3

Уязвимость функции {conn,adv}_{min,max}_interval_set() реализации протокола HCI драйвера bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации и вызвать отказ в обслуживании

Published: 2024-02-13Modified: 2025-05-06
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:A/AC:H/Au:N/C:N/I:N/A:C
References
BDU:2024-01213
MEDIUM4.7

Уязвимость функции mas_prev_slot() подсистемы управления памятью Memory Management (MM) ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-02-14Modified: 2025-01-29
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:M/Au:S/C:N/I:N/A:C
References
BDU:2024-01589
MEDIUM4.7

Уязвимость функции tls_decrypt_done (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-02-27Modified: 2026-03-11
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-01601
MEDIUM4.7

Уязвимость функции tls_encrypt_done (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-02-28Modified: 2026-03-11
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-01602
MEDIUM5.5

Уязвимость функций crypto_aead_encrypt и crypto_aead_decrypt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-02-28Modified: 2026-03-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01673
HIGH8.0

Уязвимость функции smb2_parse_contexts() в модуле fs/smb/client/smb2pdu.c клиента SMB ядра операционной системы Linux , позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2024-03-01Modified: 2025-10-24
CVSS 3.xHIGH 8.0
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.7
CVSS:2.0/AV:A/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-01681
HIGH7.8

Уязвимость функции tls_decrypt_done() модуля net/tls/tls_sw.c реализации протокола TLS (Transport Layer Security) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-03-04Modified: 2024-11-11
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-01724
HIGH7.8

Уязвимость функции nft_set_rbtree (net/netfilter/nft_set_rbtree.c) компонента Netfilter операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-03-04Modified: 2025-02-13
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-01736
MEDIUM5.5

Уязвимость функции sys_membarrier компонента membarrier ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-05Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01747
MEDIUM5.5

Уязвимость функции binder_enqueue_thread_work_ilocked() в модуле drivers/android/binder.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-05Modified: 2025-02-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01751
HIGH8.4

Уязвимость функции __thp_get_unmapped_area() подсистемы управления памятью на 32-битных системах ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-05Modified: 2024-12-06
CVSS 3.xHIGH 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-01832
HIGH7.1

Уязвимость функции i801_block_transaction_by_block() в модуле drivers/i2c/busses/i2c-i801.c драйвера шины I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-11Modified: 2025-08-19
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-01840
MEDIUM6.7

Уязвимость функции mlxsw_sp_acl_tcam_init() в модуле drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c драйвера сетевых карт Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие

Published: 2024-03-11Modified: 2025-08-19
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-01846
MEDIUM5.5

Уязвимость функции mlxsw_sp_acl_tcam_region_destroy() в модуле drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c драйвера сетевых карт Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-11Modified: 2025-10-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01847
MEDIUM6.2

Уязвимость функции nsim_destroy() в модуле drivers/net/netdevsim/netdev.c драйвера виртуального сетевого netdevsim устройства ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-11Modified: 2024-12-04
CVSS 3.xMEDIUM 6.2
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2024-01850
HIGH7.8

Уязвимость функции check_stack_slot_within_bounds() в модуле kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-03-11Modified: 2024-09-12
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-01853
MEDIUM5.5

Уязвимость функции ext4_mb_generate_buddy() в модуле fs/ext4/mballoc.c файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-03-11Modified: 2024-12-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.4
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:P/A:P
References
BDU:2024-01854
MEDIUM5.5

Уязвимость функции restore_fpregs_from_user() в модуле arch/x86/kernel/fpu/signal.c драйвера FPU ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-03-11Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01861
MEDIUM5.5

Уязвимость функции z_erofs_do_map_blocks() в модуле fs/erofs/zmap.c файловой системы erofs (Enhanced Read-Only File System) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-11Modified: 2024-12-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2024-01863
MEDIUM6.5

Уязвимость функциях map_usb_set_vbus() и omap_usb_start_srp() в модуле drivers/phy/ti/phy-omap-usb2.c драйвера USB устройств TI (Texas Instruments) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-11Modified: 2025-08-19
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-01977
MEDIUM5.5

Уязвимость функции skb_segment компонента Net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-03-14Modified: 2024-11-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-03614
MEDIUM4.4

Уязвимость функции i2c_hid_of_probe() драйвера HID устройств шины I2C ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03615
HIGH7.0

Уязвимость функции __unix_gc() в модуле net/unix/garbage.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-03620
MEDIUM4.1

Уязвимость функции nci_free_device() реализации NFC Controller Interface (NCI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-11-26
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L
CVSS 2.0LOW 2.7
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2024-03621
HIGH7.8

Уязвимость функции __prep_cap() файловой системы ceph ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2026-02-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03622
MEDIUM4.1

Уязвимость функции __sev_platform_shutdown_locked() драйвера крипографического сопроцессора AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-11-11
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-03623
MEDIUM5.5

Уязвимость функции ext4_move_extents() в модуле fs/ext4/move_extent.c файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03624
MEDIUM4.4

Уязвимость функции dwc3_gadget_suspend() драйвера USB DesignWare ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-05-21
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03625
MEDIUM5.5

Уязвимость функции nft_pipapo_remove() в модуле net/netfilter/nft_set_pipapo.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03634
MEDIUM5.5

Уязвимость функции __i915_vma_active() в модуле drivers/gpu/drm/i915/i915_vma.c драйвера графических адаптеров Intel 8xx/9xx/G3x/G4x/HD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03636
MEDIUM5.5

Уязвимость функции nfs_direct_commit_schedule() в модуле fs/nfs/direct.c сетевой файловой системы Network File System (NFS) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03637
MEDIUM5.5

Уязвимость функции free_swap_and_cache() в модуле mm/swapfile.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03639
MEDIUM5.5

Уязвимость функции max310x_i2c_probe() в модуле drivers/tty/serial/max310x.c драйвера max310x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-11-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03640
MEDIUM5.5

Уязвимость функции __handle_ksmbd_work() реализации сетевого протокола SMB (Server Message Block) внутриядерного CIFS/SMB3-сервера ksmbd server ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03641
MEDIUM6.4

Уязвимость функций ncm_set_alt() и ncm_disable() в модуле drivers/usb/gadget/function/f_ncm.c драйвера USB gadget ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xMEDIUM 6.4
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03642
MEDIUM5.5

Уязвимость функции mtk_spi_interrupt() в модуле drivers/spi/spi-mt65xx.c драйвера Mediatek SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03643
MEDIUM5.2

Уязвимость функции dvb_register_device() в модуле drivers/media/dvb-core/dvbdev.c драйвера DVB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 5.2
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:L/AC:H/Au:S/C:P/I:P/A:C
References
BDU:2024-03656
MEDIUM5.9

Уязвимость функции check_for_locks() в модуле fs/nfsd/nfs4state.c сервера файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-12-04
CVSS 3.xMEDIUM 5.9
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 5.4
CVSS:2.0/AV:N/AC:H/Au:N/C:N/I:N/A:C
References
BDU:2024-03662
MEDIUM5.5

Уязвимость функции link_set_dsc_pps_packet() в модуле drivers/gpu/drm/amd/display/dc/link/link_dpms.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03663
HIGH7.8

Уязвимость функции stack_map_alloc() в модуле kernel/bpf/stackmap.c подсистемы BPF ядра операционной системы Linux на 32-битных архитектурах, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2024-09-16
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03664
HIGH7.8

Уязвимость функции htab_map_alloc() в модуле kernel/bpf/hashtab.c подсистемы BPF ядра операционной системы Linux на 32-битных архитектурах, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2024-11-26
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03665
HIGH7.8

Уязвимость функции dev_map_init_map() в модуле kernel/bpf/devmap.c подсистемы BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03666
HIGH7.8

Уязвимость функции set_eth_seg() в модуле drivers/infiniband/hw/mlx5/wr.c драйвера Mellanox 5-го поколения сетевых адаптеров (серии ConnectX) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03667
MEDIUM5.5

Уязвимость функции sof_ipc3_fw_parse_ext_man() в модуле sound/soc/sof/ipc3-loader.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-09-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03668
MEDIUM4.4

Уязвимость функции cifs_debug_files_proc_show() в модуле fs/smb/client/cifs_debug.c подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03671
HIGH8.8

Уязвимость функции mac802154_llsec_key_del() в модуле net/mac802154/llsec.c подсистемы беспроводной связи ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и целостность защищаемой информации, или вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03676
MEDIUM5.5

Уязвимость функции sk_psock_verdict_data_ready() в модуле net/core/skmsg.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03678
MEDIUM5.5

Уязвимость функции seg6_init() в модуле net/ipv6/seg6.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03679
MEDIUM4.4

Уязвимость функции cdns3_gadget_giveback() в модуле drivers/usb/cdns3/cdns3-gadget.c драйвера USB Cadence ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2024-11-11
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03680
MEDIUM6.0

Уязвимость функции cdns3_gadget_ep_disable() в модуле drivers/usb/cdns3/cdns3-gadget.c драйвера USB Cadence ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-01-29
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-03681
MEDIUM4.4

Уязвимость функции gtp_init() в модуле drivers/net/gtp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-11-26
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03682
MEDIUM4.7

Уязвимость функции mptcp_sk_clone_init() в модуле net/mptcp/protocol.c реализации протокола Multipath TCP (MPTCP) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-03685
MEDIUM5.5

Уязвимость функции gtp_init() в модуле drivers/net/gtp.c реализации протокола GPRS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-11-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03686
MEDIUM5.5

Уязвимость функции hci_error_reset() в модуле net/bluetooth/hci_core.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03695
HIGH7.0

Уязвимость функции tcp_twsk_purge() в модуле net/ipv4/tcp_minisocks.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-10-24
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-03696
MEDIUM5.5

Уязвимость функции sparx5_del_mact_entry() в модуле drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c драйвера sparx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03697
MEDIUM5.5

Уязвимость функции bnx2x_set_fw_mac_addr() в модуле drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h драйвера Broadcom NetXtremeII 10Gb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03698
MEDIUM5.5

Уязвимость функции fsl_lpspi_probe() в модуле drivers/spi/spi-fsl-lpspi.c драйвера SPI (Serial Peripheral Interface) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2024-08-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03700
MEDIUM5.5

Уязвимость функции wilc_netdev_cleanup() в модуле drivers/net/wireless/microchip/wilc1000/netdev.c драйвера Atmel WILC1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03701
MEDIUM4.4

Уязвимость функции dm_sw_fini() в модуле drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию

Published: 2024-05-15Modified: 2026-01-20
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2024-03702
MEDIUM4.4

Уязвимость функции smc_chan_free() в модуле drivers/firmware/arm_scmi/smc.c реализации протокола ARM System Control and Management Interface (SCMI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03703
MEDIUM5.5

Уязвимость функции inet_frag_reasm_prepare() в модуле net/ipv4/inet_fragment.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03708
HIGH7.8

Уязвимость функции ip_tunnel_rcv() в модуле net/ipv4/ip_tunnel.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-15Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03712
MEDIUM5.5

Уязвимость функции kfd_ioctl_get_process_apertures_new() в модуле drivers/gpu/drm/amd/amdkfd/kfd_chardev.c драйвера amdkfd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-15Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03747
HIGH7.0

Уязвимость функции run_spu_dma() в модуле sound/sh/aica.c звуковой подсистемы (ALSA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-16Modified: 2025-05-06
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03751
MEDIUM4.7

Уязвимость функции hugetlbfs_parse_param() в модуле fs/hugetlbfs/inode.c системы управления памятью HugeTLB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-16Modified: 2025-05-05
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-03753
MEDIUM5.5

Уязвимость функции taprio_parse_tc_entry() в модуле net/sched/sch_taprio.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-16Modified: 2024-11-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03754
MEDIUM5.5

Уязвимость функции print_absolute_relocs() ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2024-05-16Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2024-03763
MEDIUM6.2

Уязвимость функции sr9800_bind() в модуле drivers/net/usb/sr9800.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-16Modified: 2025-05-06
CVSS 3.xMEDIUM 6.2
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2024-03771
MEDIUM4.7

Уязвимость функции nf_tables_unbind_set() в модуле net/netfilter/nf_tables_api.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-16Modified: 2025-08-19
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-03773
MEDIUM4.4

Уязвимость функции edp_setup_replay() в модуле drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c драйвера amdgpu видеокарт AMD Radeon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-16Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03932
MEDIUM5.5

Уязвимость функции ovs_ct_limit_exit() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03933
MEDIUM5.5

Уязвимость функции gtp_dellink() реализации протокола туннелирования GPRS ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-20Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03934
HIGH7.8

Уязвимость функции packet_buffer_get() драйвера IEEE 1394 (FireWire) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-20Modified: 2026-03-04
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-03935
MEDIUM5.5

Уязвимость функции amdgpu_bo_move() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-20Modified: 2025-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03936
MEDIUM5.5

Уязвимость функции l2cap_chan_timeout() подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-20Modified: 2026-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03937
MEDIUM5.5

Уязвимость функции sco_sock_timeout() подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-20Modified: 2026-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03939
MEDIUM5.5

Уязвимость функции xennet_alloc_one_rx_buffer() ядра операционной системы Linux, позволяющая нарушителю вызвыать отказ в обслуживании

Published: 2024-05-20Modified: 2024-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-03941
MEDIUM6.5

Уязвимость функции io_uring_get_file() подсистемы io_uring ядра Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-20Modified: 2025-10-24
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04137
HIGH8.4

Уязвимость функции tomoyo_write_control() подсистемы безопасности TOMOYO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-05-28Modified: 2024-11-11
CVSS 3.xHIGH 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-04216
MEDIUM5.5

Уязвимость функции check_kprobe_address_safe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04217
MEDIUM5.5

Уязвимость функции ax25_dev_device_down() реализации протокола Amateur Radio X.25 PLP (Rose) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2024-08-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04218
MEDIUM5.5

Уязвимость функции smb2_reconnect_server() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2025-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04219
MEDIUM5.5

Уязвимость функции cifs_stats_proc_write() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04220
MEDIUM5.5

Уязвимость функции cifs_stats_proc_show() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04221
MEDIUM5.5

Уязвимость функции cifs_dump_full_key() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04222
MEDIUM5.5

Уязвимость функции smb2_is_valid_oplock_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2024-12-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04223
MEDIUM5.5

Уязвимость функции smb2_is_valid_lease_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04224
MEDIUM5.5

Уязвимость функции is_valid_oplock_break() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04225
MEDIUM5.5

Уязвимость функции smb2_is_network_name_deleted() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04226
MEDIUM5.5

Уязвимость функции cifs_signal_cifsd_for_reconnect() реализации клиента протокола SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04227
MEDIUM5.5

Уязвимость функции mlxsw_sp_acl_tcam_ventry_activity_get() драйвера Mellanox Technologies Switch ASICs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04228
HIGH8.8

Уязвимость функции mlxsw_sp_acl_tcam_vregion_rehash() драйвера Mellanox Technologies Switch ASICs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2025-08-19
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0CRITICAL 9.0
CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04229
MEDIUM5.5

Уязвимость функции brcmf_notify_escan_complete() драйвера Broadcom FullMAC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2024-09-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04232
MEDIUM5.5

Уязвимость функции sev_mem_enc_register_region() компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04233
HIGH7.1

Уязвимость функции optee_register_device() драйвера Trusted Execution Environment (TEE) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2026-02-09
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-04234
MEDIUM5.5

Уязвимость функции pep_ioctl() реализации протокола PhoNet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-05-30Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04369
HIGH7.0

Уязвимость функции nf_tables_abort() компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-05Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-04539
HIGH7.1

Уязвимость функции ath12k_htt_pull_ppdu_stats() драйвера ath12k (Qualcomm Technologies Wi-Fi 7) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-06-14Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-04541
MEDIUM6.4

Уязвимость функции msft_do_close() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-14Modified: 2025-10-24
CVSS 3.xMEDIUM 6.4
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-04542
MEDIUM5.5

Уязвимость функции register_device() драйвера символьных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04543
MEDIUM5.5

Уязвимость функции malidp_mw_connector_reset() драйвера ARM Mali Display Processor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-14Modified: 2026-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04544
MEDIUM5.5

Уязвимость функции l2cap_connect() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-14Modified: 2026-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04546
HIGH7.8

Уязвимость функции do_setvfinfo() реализации стека протоколов TCP/IP ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-14Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04549
MEDIUM5.5

Уязвимость функции orangefs_mount() файловой системы orangefs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-14Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04551
HIGH7.8

Уязвимость функции net_alloc_generic() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-14Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04552
HIGH8.0

Уязвимость функции tipc_buf_append() реализации протокола Transparent Inter Process Communication (TIPC) ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-14Modified: 2026-02-09
CVSS 3.xHIGH 8.0
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.7
CVSS:2.0/AV:A/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04553
MEDIUM5.5

Уязвимость функции mas_empty_area_rev() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04554
HIGH7.0

Уязвимость функции gpio_chrdev_release() драйвера gpio ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-14Modified: 2025-10-29
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04555
MEDIUM6.5

Уязвимость функции ip6_output() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-14Modified: 2025-08-19
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04556
MEDIUM5.5

Уязвимость функции __fib6_rule_action() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-14Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04557
HIGH7.8

Уязвимость функции tcp_twsk_unique() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-14Modified: 2026-02-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04559
MEDIUM5.5

Уязвимость функции __spi_sync() драйвера Serial Peripheral Interface (SPI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04561
MEDIUM5.5

Уязвимость функции sk_psock_verdict_data_ready() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04564
MEDIUM5.5

Уязвимость функции setup_dsc_config() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-17Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04565
MEDIUM6.5

Уязвимость функции l2cap_le_flowctl_init() реализации протокола Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-17Modified: 2024-10-08
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04577
HIGH7.8

Уязвимость функции gfs2_put_super() файловой системы gfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-17Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04580
HIGH7.8

Уязвимость функций disable_{show,store}() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-17Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04581
HIGH7.8

Уязвимость функции interface_authorized_store() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-17Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04584
HIGH7.8

Уязвимость функции dup_mmap() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-17Modified: 2024-11-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04585
HIGH7.8

Уязвимость функции __dst_negative_advice() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-17Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-04587
HIGH7.0

Уязвимость функции nft_expr_type_get() компоненты netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-06-17Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-04589
MEDIUM5.5

Уязвимость функции scp_ipi_init() драйвера сопроцессоров ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-17Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04591
MEDIUM5.5

Уязвимость функции tpm2_key_encode() подсистемы Trusted Platform Module (TPM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-06-17Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-04680
HIGH7.8

Уязвимость функции multiq_tune компонента sch_multiq ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-06-19Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.6
CVSS:2.0/AV:N/AC:H/Au:N/C:C/I:C/A:C
References
BDU:2024-04895
MEDIUM5.5

Уязвимость функции alauda_init_media() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-07-01Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2024-04910
HIGH7.8

Уязвимость функции del_timer() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или оказать иное воздействие

Published: 2024-07-01Modified: 2025-02-25
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-05057
MEDIUM5.5

Уязвимость функции btrfs_set_item_key_safe() ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-07-05Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-05829
MEDIUM4.1

Уязвимость функции kfree_sensitive ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию

Published: 2024-07-30Modified: 2025-10-24
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:N/A:N
References
BDU:2024-05830
MEDIUM4.1

Уязвимость функции copy_to_user компонента s390 ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию

Published: 2024-07-30Modified: 2025-10-24
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:N/A:N
References
BDU:2024-06043
HIGH7.8

Уязвимость функции smb2_get_data_area_len() реализации сервера протокола SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2025-10-23
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06044
MEDIUM4.4

Уязвимость функции gp_aux_bus_probe() драйвера Microchip PCI1XXXX ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06045
MEDIUM5.5

Уязвимость функции tpm2_key_encode() подсистемы Trusted Platform Module (TPM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06047
MEDIUM4.4

Уязвимость функции __dwc3_stop_active_transfer() драйвера DesignWare USB3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06048
MEDIUM6.1

Уязвимость функции taprio_parse_mqprio_opt() подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:C
References
BDU:2024-06050
HIGH7.8

Уязвимость функций sbi_cpu_start() и cpu_update_secondary_bootdata() ядра операционной системы Linux на процессорах с архитектурой RISC-V, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2025-02-05
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06051
HIGH7.8

Уязвимость функции do_map_benchmark() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06054
MEDIUM5.5

Уязвимость функции parse_btf_field() подсистемы трассировки ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06055
MEDIUM5.5

Уязвимость функции sync_print_obj() драйвера dma-buf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06056
MEDIUM5.5

Уязвимость функции register_winch_irq() драйвера подсистемы User-Mode Linux (UML) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06057
MEDIUM4.7

Уязвимость функции may_update_sockmap() подсистемы BPF ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации

Published: 2024-08-07Modified: 2025-04-30
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:C/A:N
References
BDU:2024-06058
HIGH7.8

Уязвимость функции br_mst_set_state() реализации протокола IEEE 802.1D ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 5.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:P/A:C
References
BDU:2024-06060
HIGH7.8

Уязвимость функции stm_register_device() драйвера трассировки System Trace Module (STM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06062
HIGH7.8

Уязвимость функции amdgpu_mes_remove_ring() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06063
HIGH7.1

Уязвимость функции bond_option_arp_ip_targets_set() сетевой компоненты ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-08-07Modified: 2026-03-04
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:C
References
BDU:2024-06065
MEDIUM5.5

Уязвимость функции sof_ipc4_get_input_pin_audio_fmt() звуковой подсистемы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06066
MEDIUM5.5

Уязвимость функции vm_area_alloc_pages() менеджера памяти ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06069
MEDIUM4.7

Уязвимость функции netpoll_owner_active() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации

Published: 2024-08-07Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-06071
HIGH7.8

Уязвимость функции btrfs_load_zone_info() файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06072
HIGH7.8

Уязвимость функции gb_interface_release() драйвера Greybus ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06073
HIGH7.8

Уязвимость функции ima_collect_measurement() компонента IMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06081
MEDIUM5.5

Уязвимость функции __v4l2_async_nf_unregister() видео драйвера ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации

Published: 2024-08-07Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06082
MEDIUM5.5

Уязвимость структуры davinci_mmcsd_driver драйвера MMC/SD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06083
MEDIUM5.5

Уязвимость функции media_pipeline_explore_next_link() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06084
HIGH7.8

Уязвимость функции kdb_read() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-07Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06088
MEDIUM5.5

Уязвимость функции raid5d() драйвера блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06089
MEDIUM5.5

Уязвимость функции savagefb_probe() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-07Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06349
MEDIUM5.5

Уязвимость функции dm_table_create() в модуле drivers/md/dm-table.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-21Modified: 2024-11-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06488
MEDIUM5.5

Уязвимость функции ip_route_use_hint() в компоненте ipv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06493
MEDIUM4.7

Уязвимость функции synchronize_rcu() в компоненте ipset ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2024-11-06
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-06494
MEDIUM4.7

Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2026-01-20
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-06495
MEDIUM5.5

Уязвимость компонента rfcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06496
MEDIUM5.5

Уязвимость функции do_sys_name_to_handle() в компоненте kernel-infoleak ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06497
MEDIUM5.5

Уязвимость функции i2c_hid_xfer() в компоненте i2c-hid ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06498
MEDIUM5.5

Уязвимость компонента xilinx_dpdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06499
MEDIUM5.5

Уязвимость компонента smbus ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06500
MEDIUM5.5

Уязвимость компонента batman-adv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06501
MEDIUM5.5

Уязвимость функции hci_req_sync_complete() в компоненте Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06502
MEDIUM4.7

Уязвимость функции __nft_obj_type_get() в компоненте nf_tables ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию

Published: 2024-08-27Modified: 2025-08-19
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:N/A:N
References
BDU:2024-06503
MEDIUM5.5

Уязвимость компонента tun ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06521
MEDIUM5.5

Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06522
CRITICAL9.8

Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-08-27Modified: 2025-08-19
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-06524
MEDIUM5.5

Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-08-27Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06716
MEDIUM4.7

Уязвимость функции dispose_list в компоненте vfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-06Modified: 2025-05-06
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06732
HIGH7.1

Уязвимость функции gtp_dev_xmit() модуля drivers/net/gtp.c ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-09-06Modified: 2025-05-06
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-06733
HIGH7.8

Уязвимость функций select_local_address() и select_signal_address компонента mptcp ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-09-06Modified: 2026-04-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06745
HIGH7.8

Уязвимость функции dequeue_rx() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-09-06Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06751
HIGH7.8

Уязвимость функции ip6_xmit() ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-09Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06753
HIGH7.8

Уязвимость функции ip6_finish_output2 ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-09Modified: 2025-05-01
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06759
MEDIUM5.5

Уязвимость функции tcp_sk_exit_batch() ядра операционных систем Linux, позволяющая нарушителю оказать воздействие на доступность защищаемой информации

Published: 2024-09-09Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06857
MEDIUM5.5

Уязвимость компонента thermal/drivers/tsens ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-12Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06858
HIGH7.8

Уязвимость компонента net/mlx5 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-09-12Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06859
MEDIUM5.5

Уязвимость компонента ssh_css ядра операционной системы Linux, связанная с разыменованием NULL указателя, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-12Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06860
MEDIUM5.5

Уязвимость компонента vc4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-12Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-06861
HIGH7.8

Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-09-12Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06895
CRITICAL9.1

Уязвимость компонента drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c ядра операционной системы Linux, связанная с недостаточной обработкой форматной строки, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании

Published: 2024-09-13Modified: 2025-08-19
CVSS 3.xCRITICAL 9.1
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0CRITICAL 9.4
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:N/A:C
References
BDU:2024-06899
HIGH7.5

Уязвимость компонента drivers/usb/gadget/function/f_ncm.c ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-13Modified: 2026-01-20
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2024-06900
HIGH7.8

Уязвимость драйвера AoE ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании

Published: 2024-09-13Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06901
HIGH7.8

Уязвимость ядра операционной системы Linux, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании

Published: 2024-09-13Modified: 2024-11-12
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06929
HIGH8.4

Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании

Published: 2024-09-13Modified: 2024-11-12
CVSS 3.xHIGH 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-06989
HIGH7.8

Уязвимость компонента arch/x86/kernel/fpu/xstate.c ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании

Published: 2024-09-13Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-06991
HIGH8.4

Уязвимость функции mi_enum_attr() компонента fs/ntfs3 ядра операционной системы Linux, связанная с копированием буфера без проверки входных данных, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании

Published: 2024-09-13Modified: 2026-01-20
CVSS 3.xHIGH 8.4
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.2
CVSS:2.0/AV:L/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-07049
MEDIUM4.7

Уязвимость функции unix_release_sock/unix_stream_sendmsg компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-16Modified: 2025-08-19
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-07094
MEDIUM5.5

Уязвимость библиотеки lib/xarray.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-17Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07389
MEDIUM4.1

Уязвимость функции rb_get_reader_page компонента kernel/trace/ring_buffer.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-23Modified: 2025-05-06
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-07403
MEDIUM5.5

Уязвимость компонента HCI_AMP ядра операционной системы Linux, позволяющая нарушителю, вызвать отказ в обслуживании

Published: 2024-09-24Modified: 2024-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07405
MEDIUM5.5

Уязвимость функции shmem_is_huge() подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-24Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07483
MEDIUM6.3

Уязвимость функции fcntl_setlk() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-09-24Modified: 2025-08-19
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:N/A:C
References
BDU:2024-07484
HIGH7.8

Уязвимость функции criu_restore_memory_of_gpu() драйвера amdkfd ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-09-24Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07630
HIGH7.0

Уязвимость компонента fastrpc ядра операционной системы Linux, позволяющая нарушению оказывать влияние на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-09-30Modified: 2024-10-18
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07636
MEDIUM5.5

Уязвимость компонента RDMA/hns ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код

Published: 2024-09-30Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07637
MEDIUM5.5

Уязвимость компонента RDMA/hns ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании

Published: 2024-09-30Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07638
HIGH7.8

Уязвимость функции nilfs_segctor_notify() файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-09-30Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07639
MEDIUM5.5

Уязвимость компонента drm/mediatek ядра операционной системы Linux, позволяющая нарушению вызвать отказ в обслуживании

Published: 2024-09-30Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07640
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код

Published: 2024-09-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07641
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07642
MEDIUM5.5

Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-09-30Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07692
HIGH7.0

Уязвимость функции tcf_ct_act() подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-03Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-07741
HIGH7.0

Уязвимость функции amdgpu_vce_ring_parse_cs() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-10-24
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-07744
HIGH7.5

Уязвимость функции mt76_connac_mcu_add_nested_tlv() драйвера MediaTek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-10-24
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:A/AC:H/Au:N/C:C/I:C/A:C
References
BDU:2024-07745
MEDIUM6.1

Уязвимость функции mv88e6xxx_default_mdio_bus() драйвера устройств Marvell 88E6xxx ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-10-24
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:C
References
BDU:2024-07746
HIGH7.8

Уязвимость макроопределения BPF_CORE_READ_BITFIELD компонента bpf ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07747
HIGH7.8

Уязвимость функции f2fs_build_fault_attr() файловой системы f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07748
HIGH7.8

Уязвимость функции mpi3mr_sas_port_add() драйвера устройств Broadcom MPI3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07750
HIGH7.8

Уязвимость функции tcpm_register_source_caps() драйвера контроллера USB Type-C ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07751
HIGH7.8

Уязвимость функции ea_get() файловой системы jfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07757
HIGH7.8

Уязвимость функции gfs2_glock_free() файловой системы gfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07758
HIGH7.8

Уязвимость функции show_rcu_tasks_trace_gp_kthread() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-04Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07925
MEDIUM5.5

Уязвимость компонента sqpoll операционной системы Linux, связанная с ошибкой освобождения памяти, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-10Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07926
HIGH7.8

Уязвимость функции add_ra_bio_pages() файловой системы btrfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-10Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2024-07927
HIGH7.8

Уязвимость функции msi_capability_init() в модуле drivers/pci/msi/msi.c драйвера Message Signaled Interrupts (MSI and MSI-X) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-10Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2024-07928
HIGH7.8

Уязвимость функции v9fs_dentry_release() в модуле fs/9p/vfs_dentry.c файловой системы 9p ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии

Published: 2024-10-10Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-07937
HIGH7.8

Уязвимость функции cachefiles_withdraw_volumes() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-11Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07961
HIGH7.8

Уязвимость функции max_vclocks_store() (drivers/ptp/ptp_sysfs.c) реализации протокола Precision Time Protocol (PTP) ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-10-11Modified: 2025-03-21
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07965
HIGH7.8

Уязвимость функции blkpg_do_ioctl() (block/ioctl.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-11Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07983
HIGH7.8

Уязвимость функции ata_host_alloc() (drivers/ata/libata-core.c) драйвера ATA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-11Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07984
HIGH7.8

Уязвимость функции i915_vma_revoke_fence() (drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c) драйвера видеокарт Intel 8xx/9xx/G3x/G4x/HD ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии

Published: 2024-10-11Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-07985
MEDIUM5.5

Уязвимость функции swap_endian() подсистемы WireGuard ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-11Modified: 2026-04-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-07986
MEDIUM4.4

Уязвимость структуры tcp_metrics_nl_policy реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-11Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
CVSS 2.0LOW 3.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:P/A:N
References
BDU:2024-08071
HIGH7.8

Уязвимость функции seqpacket_allow() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-16Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08072
MEDIUM5.5

Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-16Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08075
HIGH7.8

Уязвимость функции dasd_ese_needs_format() ядра операционной системы Linux на платформе s390, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-16Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08077
HIGH7.8

Уязвимость функции ila_xlat_exit_net() реализации Identifier Locator Addressing (ILA) протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-16Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08078
MEDIUM5.5

Уязвимость функции mmio_read() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-16Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08082
HIGH7.8

Уязвимость функции cdrom_ioctl_timed_media_change() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-16Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08083
HIGH7.8

Уязвимость функции vmci_resource_remove() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-16Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08084
HIGH7.1

Уязвимость функции of_irq_parse_one() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-16Modified: 2026-01-20
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08085
HIGH7.8

Уязвимость функции adc128_in_store() драйвера hwmon ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-16Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08087
HIGH7.8

Уязвимость функции amdgpu_ring_init() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-16Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08133
HIGH7.1

Уязвимость функции amdgpu_cgs_get_firmware_info() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-17Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08135
HIGH7.1

Уязвимость функции df_v1_7_get_hbm_channel_number() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-17Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08139
HIGH7.8

Уязвимость функции snd_pcm_suspend_all() компонента dapm ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-10-17Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08162
HIGH7.1

Уязвимость функции cougar_report_fixup() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08164
MEDIUM5.5

Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-18Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08165
HIGH7.8

Уязвимость функции mlx5_function_teardown() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08183
MEDIUM4.7

Уязвимость функции pca953x_irq_bus_sync_unlock() драйвера GPIO ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2024-08184
HIGH7.8

Уязвимость функции binder_transaction() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08186
HIGH7.8

Уязвимость функции netem_dequeue() подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08188
MEDIUM5.5

Уязвимость компонента tcp_bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08189
MEDIUM5.5

Уязвимость компонента mcp251x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-18Modified: 2025-05-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08227
HIGH7.8

Уязвимость функции sk_common_release() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08229
HIGH7.8

Уязвимость функции do_hardware_base_addr() драйвера параллельного порта ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08230
HIGH7.8

Уязвимость структуры bnx2x_fw_stats_req драйвера QLogic ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08231
HIGH7.8

Уязвимость функции squashfs_read_inode() файловой системы squashfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08232
HIGH7.8

Уязвимость функции cma_heap_vm_fault() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08233
HIGH7.8

Уязвимость функции axg_card_add_tdm_loopback() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08234
HIGH7.8

Уязвимость функции setup_one_line() ядра операционной системы Linux в режиме User-mode-Linux (UML), позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08235
HIGH7.1

Уязвимость функции atomctrl_retrieve_ac_timing() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-10-29
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08237
HIGH7.0

Уязвимость функции mptcp_pm_del_add_timer() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-18Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-08295
HIGH7.8

Уязвимость функции fscache_exit() файловой системы netfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-03-21
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08296
HIGH7.8

Уязвимость функции amdtp_hid_remove() драйвера AMD Sensor Fusion Hub ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08302
HIGH7.8

Уязвимость функции irq_process_work_list() драйвера DMA ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08303
HIGH7.8

Уязвимость функции kvm_spapr_tce_attach_iommu_group() подсистемы виртуализации Kernel-based Virtual Machine (KVM) ядра операционной системы Linux на платформе PowerPC, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08304
HIGH7.8

Уязвимость функции get_net_ns() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08305
MEDIUM5.5

Уязвимость функций __jfs_getxattr() и jfs_listxattr() файловой системы jfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08306
HIGH7.8

Уязвимость функции posix_lock_inode() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08307
HIGH7.8

Уязвимость функции ltq_etop_free_channel() драйвера Ethernet ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08308
HIGH7.8

Уязвимость функции ftrace_location() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08310
HIGH7.1

Уязвимость функции check_rstbl() файловой системы NTFS3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08311
HIGH7.8

Уязвимость функции rtw89_sta_info_get_iter() драйвера беспроводных адаптеров Realtek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08312
MEDIUM6.7

Уязвимость функции fcntl_setlk() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08314
HIGH7.8

Уязвимость функции cachefiles_withdraw_volumes() файловой системы cachefiles ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08315
HIGH7.8

Уязвимость функции nvme_cleanup_cmd() драйвера NVMe ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08316
MEDIUM5.5

Уязвимость функции ctnetlink_del_expect() компонентa netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08317
MEDIUM5.5

Уязвимость функции kcm_sendmsg() реализации KCM (Kernel Connection Multiplexor) сокетов ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08319
HIGH7.8

Уязвимость функции hns3_pmu_validate_event_group() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08320
MEDIUM5.5

Уязвимость функции fuse_notify_store() файловой системы fuse ядра операционной системы Linux, позволяющая нарушителю раскрыть защищаемую информацию

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2024-08321
HIGH7.8

Уязвимость функции hisi_pcie_pmu_validate_event_group() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08322
HIGH7.8

Уязвимость функции update_xps() драйвера сетевых адаптеров Freescale DPAA2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08323
MEDIUM5.5

Уязвимость функции ocfs2_xattr_find_entry() файловой системы ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2026-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08324
MEDIUM5.5

Уязвимость структуры moschip7840_4port_device драйвера USB для последовательных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08325
MEDIUM5.5

Уязвимость функции entry_SYSCALL_compat() ядра операционной системы Linux на платформе x86, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08326
MEDIUM5.5

Уязвимость функции ceph_monc_stop() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08327
MEDIUM5.5

Уязвимость функции usb_string_copy() драйвера USB gadget ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08328
HIGH7.1

Уязвимость функции amdgpu_atombios_init_mc_reg_table() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08329
HIGH7.1

Уязвимость функции hfsplus_listxattr() файловой системы HFS+ ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08330
HIGH7.1

Уязвимость функции sdma_v4_0_process_trap_irq() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08331
HIGH7.8

Уязвимость функции iucv_cpu_down_prep() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08333
HIGH7.8

Уязвимость функции st_dwc3_probe() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08334
HIGH7.8

Уязвимость функции gc_data_segment() файловой системы f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08335
HIGH7.8

Уязвимость функции nilfs_check_folio() файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-23Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08346
MEDIUM5.5

Уязвимость функции proc_cpuset_show() (kernel/cgroup/cpuset.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-23Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08517
HIGH7.1

Уязвимость функции dpaa_start_xmit() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-29
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08518
HIGH7.8

Уязвимость функции acpi_pcc_hotkey_add() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-05-02
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08519
HIGH7.8

Уязвимость функции nxp_fspi_fill_txfifo() драйвера Serial Peripheral Interface (SPI) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08520
HIGH7.8

Уязвимость функции ast_udc_getstatus() драйвера usb gadget ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08523
HIGH7.8

Уязвимость макроопределения ARCH_DMA_MINALIGN ядра операционной системы Linux на платформе PA-RISC, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08525
HIGH7.8

Уязвимость функций read() и write() драйвера amdpgu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08526
HIGH7.8

Уязвимость функции dcn302_fpu_update_bw_bounding_box() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08528
HIGH7.8

Уязвимость функции hdmi_14_process_transaction() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08529
HIGH7.8

Уязвимость функции dal_gpio_service_lock() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08530
HIGH7.8

Уязвимость функции navi10_is_support_fine_grained_dpm() драйвера amdpgu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08531
HIGH7.8

Уязвимость функции aac_init_adapter() драйвера Adaptec AACRAID ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08532
HIGH7.8

Уязвимость функции gue_gro_receive() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08533
HIGH7.8

Уязвимость функции diSync() файловой системы jfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08534
HIGH7.8

Уязвимость функции tipc_udp_addr2str() реализации протокола TIPC (Transparent Inter Process Communication) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08535
HIGH7.8

Уязвимость функции hfcmulti_tx() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08539
HIGH7.8

Уязвимость функции iucv_sever_path() драйвера IUCV ядра операционной системы Linux на платформе s/390, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08540
HIGH7.8

Уязвимость функции ta_if_load_debugfs_write() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-10-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08626
MEDIUM5.5

Уязвимость компонента cxl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08630
MEDIUM5.5

Уязвимость компонента target ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08633
MEDIUM5.5

Уязвимость компонента virtio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08636
MEDIUM5.5

Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08637
MEDIUM5.5

Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08642
MEDIUM5.5

Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08646
MEDIUM5.5

Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08649
MEDIUM5.5

Уязвимость компонента nvmet-fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08661
HIGH7.8

Уязвимость компонентов IB/hfi1 ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код и повысить свои привилегии

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08664
LOW3.3

Уязвимость компонента dm-crypt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2026-01-20
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:N
References
BDU:2024-08665
MEDIUM5.5

Уязвимость компонента l2tp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08666
MEDIUM5.5

Уязвимость компонента ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08667
MEDIUM5.5

Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08668
MEDIUM5.5

Уязвимость компонента srpt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08669
MEDIUM5.5

Уязвимость компонента qedr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08670
HIGH8.8

Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08671
HIGH8.8

Уязвимость компонента afs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08672
HIGH8.8

Уязвимость компонента arp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-08-19
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08673
MEDIUM5.5

Уязвимость компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08674
MEDIUM5.5

Уязвимость компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08676
MEDIUM5.5

Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08677
MEDIUM5.5

Уязвимость компонента rt5645 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-04-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08681
MEDIUM5.5

Уязвимость компонентов fs/aio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08731
MEDIUM5.5

Уязвимость функции cs_dsp_load() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-29Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08737
MEDIUM5.5

Уязвимость функции cs_dsp_load() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-30Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08738
MEDIUM5.5

Уязвимость функции BPF_CALL_1() компонента BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-10-30Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-08915
HIGH7.8

Уязвимость функции cs_dsp_dbg() (drivers/firmware/cirrus/cs_dsp.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-02Modified: 2025-08-19
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08978
HIGH7.0

Уязвимость функции venus_remove() драйвера Qualcomm Venus V4L2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-10-29
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-08979
HIGH7.8

Уязвимость определения массивов dmub_callback и dmub_thread_offload ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08980
HIGH7.8

Уязвимость функции f2fs_do_shutdown() файловой системы f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-03-21
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08981
HIGH7.8

Уязвимость функции bfq_init_rq() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-05-02
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08982
HIGH7.1

Уязвимость функции nilfs_btree_check_delete() файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-10-29
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-08983
CRITICAL9.1

Уязвимость функции nf_reject_ip6_tcphdr_put() компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-11-06Modified: 2026-01-20
CVSS 3.xCRITICAL 9.1
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0CRITICAL 9.4
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:N/A:C
References
BDU:2024-08984
HIGH8.8

Уязвимость функции smack_inet_conn_request() реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-10-24
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0CRITICAL 9.0
CVSS:2.0/AV:N/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08985
HIGH7.8

Уязвимость функции ocfs2_xattr_find_entry() файловой системы ocfs2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08988
HIGH7.8

Уязвимость функции sd_read_block_characteristics() драйвера SCSI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08989
HIGH7.8

Уязвимость функции rtl2830_pid_filter() драйвера Realtek RTL2830 DVB-T ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08990
HIGH7.8

Уязвимость функции rtl2832_pid_filter() драйвера Realtek RTL2830 DVB-T ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08991
HIGH7.8

Уязвимость функции handle_mmio() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08993
HIGH7.8

Уязвимость функции hns_roce_v2_exit() драйвера Hisilicon Hip08 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08994
HIGH7.8

Уязвимость функции kirin_pcie_parse_port() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08995
HIGH7.8

Уязвимость функции efc_nport_vport_del() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08996
HIGH7.8

Уязвимость функции scmi_optee_chan_free() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-08997
HIGH7.0

Уязвимость функции ether3_remove() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-10-29
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-08998
HIGH7.0

Уязвимость функции nbd_requeue_cmd() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-05-06
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-09000
HIGH7.0

Уязвимость функции l2cap_sock_recv_cb() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-10-24
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-09001
HIGH7.8

Уязвимость функции hns_roce_cq_event() драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-03-21
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09003
HIGH7.8

Уязвимость функции pxafb_remove() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09004
HIGH7.8

Уязвимость функции xenvif_flush_hash() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2026-03-12
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09005
HIGH7.8

Уязвимость функции __ext4_fill_super() файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09006
HIGH7.8

Уязвимость функции ext4_ext_replay_update_ex() файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-06Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09007
HIGH7.8

Уязвимость функции x86_android_tablet_probe() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09008
HIGH7.8

Уязвимость функции link_destruct() драйвера amdgpu ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2025-12-26
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09009
HIGH7.8

Уязвимость функции ltdc_plane_create() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-06Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09016
MEDIUM5.5

Уязвимость функции ext4_mb_find_by_goal() ядра операционной системы Linux, связанная с выходом операции за границы буфера в памяти, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-07Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09028
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с недостаточной нейтрализацией специальных элементов в запросе, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-07Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09031
MEDIUM5.5

Уязвимость компонента fs/ntfs3 ядра операционной системы Linux, связанная с ошибками разыменования указателя, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-07Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09130
MEDIUM5.5

Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09132
MEDIUM5.5

Уязвимость компонента fsl-qdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09134
MEDIUM5.5

Уязвимость компонентов dmaengine ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09149
MEDIUM5.5

Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09152
HIGH8.8

Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-08-19
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09153
MEDIUM5.5

Уязвимость компонента savage ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09154
MEDIUM5.5

Уязвимость компонента sis ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09155
MEDIUM5.5

Уязвимость компонента hisi-sfc-v3xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09156
MEDIUM5.5

Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09158
MEDIUM5.5

Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09159
MEDIUM5.5

Уязвимость компонента edma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09160
HIGH8.8

Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-08Modified: 2025-09-05
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09162
MEDIUM5.5

Уязвимость компонента b43 ядра операционной системы Linux, связанная с циклом с недостижимым условием выхода, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09163
MEDIUM5.5

Уязвимость компонента nvme-fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09164
MEDIUM5.5

Уязвимость компонента target ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09165
MEDIUM5.5

Уязвимость компонента efi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09166
MEDIUM5.5

Уязвимость компонента hfi1 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09167
MEDIUM5.5

Уязвимость компонента irdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09168
MEDIUM5.5

Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09172
MEDIUM5.5

Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09173
MEDIUM5.5

Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09175
MEDIUM5.5

Уязвимость компонента hv_netvsc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09176
MEDIUM5.5

Уязвимость компонента iio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09179
MEDIUM5.5

Уязвимость компонента zswap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09183
MEDIUM5.5

Уязвимость компонентов vfio/pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09184
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09186
MEDIUM5.5

Уязвимость компонента cachefiles ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09187
MEDIUM5.5

Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09189
MEDIUM4.4

Уязвимость компонента rc ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2024-11-08Modified: 2026-01-20
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
CVSS 2.0LOW 3.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:P/A:N
References
BDU:2024-09190
MEDIUM5.5

Уязвимость компонентов powerpc/pseries/iommu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09194
MEDIUM5.5

Уязвимость компонентов fbcon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09196
MEDIUM5.5

Уязвимость компонента stmmac ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09198
MEDIUM5.5

Уязвимость компонента veth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09199
HIGH8.8

Уязвимость компонента ip_tunnel ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-08Modified: 2025-08-19
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09201
MEDIUM5.5

Уязвимость компонента netlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09203
MEDIUM5.5

Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании(DoS)

Published: 2024-11-08Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09204
MEDIUM5.5

Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09205
MEDIUM5.5

Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании(DoS)

Published: 2024-11-08Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09206
MEDIUM5.5

Уязвимость компонента vfio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09207
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-08Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09208
LOW3.3

Уязвимость компонента stm32 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-08Modified: 2025-05-06
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-09321
LOW3.3

Уязвимость компонента sysfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-13Modified: 2025-08-19
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-09322
MEDIUM5.5

Уязвимость компонента speakup ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09326
MEDIUM5.5

Уязвимость компонентов serial/pmac_zilog ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09328
MEDIUM5.5

Уязвимость компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09329
MEDIUM5.5

Уязвимость компонента vmk80xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09330
MEDIUM5.5

Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09332
MEDIUM5.5

Уязвимость компонента drm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09339
MEDIUM5.5

Уязвимость компонентов s390/cio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09340
HIGH7.8

Уязвимость компонента binder ядра операционной системы Linux, позволяющая нарушителю выполнять произвольный код

Published: 2024-11-13Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09343
MEDIUM5.5

Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09352
LOW3.3

Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-13Modified: 2025-04-29
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-09355
MEDIUM5.5

Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09356
MEDIUM5.5

Уязвимость компонентов powerpc/pseries ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09358
MEDIUM5.5

Уязвимость компонента md ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09367
MEDIUM5.5

Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09368
MEDIUM5.5

Уязвимость компонентов nouveau/dmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09369
MEDIUM5.5

Уязвимость компонентов kprobes/x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09370
MEDIUM5.5

Уязвимость компонентов mm/memory-failure ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09373
MEDIUM5.5

Уязвимость компонента dwc3-am62 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-13Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09393
MEDIUM5.5

Уязвимость компонента qla2xxx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09394
LOW3.3

Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-14Modified: 2025-05-06
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-09396
MEDIUM5.5

Уязвимость компонентов drm/i915/gt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09397
MEDIUM5.5

Уязвимость компонента wireguard ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09398
HIGH8.8

Уязвимость компонента wireguard ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-14Modified: 2026-01-20
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09399
MEDIUM5.5

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09400
MEDIUM5.5

Уязвимость функции pci_iounmap() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09401
HIGH7.0

Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-08-19
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09403
HIGH8.8

Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-14Modified: 2025-08-19
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09405
LOW3.3

Уязвимость компонента fat ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-14Modified: 2025-08-19
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-09406
MEDIUM5.5

Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09409
MEDIUM5.5

Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09410
MEDIUM5.5

Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09411
MEDIUM5.5

Уязвимость компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09412
MEDIUM5.5

Уязвимость компонента xhci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09414
HIGH8.8

Уязвимость компонентов s390/zcrypt ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-14Modified: 2025-10-24
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09415
MEDIUM5.5

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09450
MEDIUM5.5

Уязвимость функции rm3100_common_probe() компонента drivers/iio/magnetometer/rm3100-core.c ядра операционной системы Linux, связанная с чтением за допустимыми границами буфера данных, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-14Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09524
HIGH7.1

Уязвимость функций nf_flow_offload_inet_hook() и nf_flow_skb_encap_protocol() компонента netfilter ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2024-11-14Modified: 2026-01-20
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2024-09526
HIGH7.8

Уязвимость функции ip6_send_skb() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-14Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09527
HIGH7.8

Уязвимость функции br_multicast_del_port() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-14Modified: 2025-05-01
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09716
MEDIUM5.5

Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09723
MEDIUM5.5

Уязвимость компонента flower ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09725
MEDIUM5.5

Уязвимость компонента dsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09726
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09728
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09729
MEDIUM5.5

Уязвимость компонента zynq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09731
MEDIUM5.5

Уязвимость компонента clk ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09755
MEDIUM5.5

Уязвимость компонента fsl-qdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09756
MEDIUM5.5

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09757
MEDIUM5.5

Уязвимость компонента octeontx2-af ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09758
MEDIUM5.5

Уязвимость компонента nbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09759
LOW3.3

Уязвимость компонента NTB ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-18Modified: 2025-03-21
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-09767
HIGH7.8

Уязвимость компонента usb-audio ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09768
MEDIUM5.5

Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09769
MEDIUM5.5

Уязвимость компонента ethernet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09770
MEDIUM5.5

Уязвимость компонента qbman ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09771
MEDIUM5.5

Уязвимость компонента dm snapshot ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09772
MEDIUM5.5

Уязвимость компонента x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-18Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09776
HIGH7.8

Уязвимость функции vdec_close() драйвера Qualcomm Venus V4L2 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09777
HIGH7.8

Уязвимость функции iw_destroy_cm_id() драйвера InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09788
HIGH7.8

Уязвимость функции ext4_ext_try_to_merge_up() файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-18Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09789
HIGH7.8

Уязвимость функции ext4_ext_insert_extent() файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-18Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09790
HIGH7.8

Уязвимость функции ext4_split_extent_at() файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-18Modified: 2026-03-12
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09791
HIGH7.8

Уязвимость функции ext4_ext_handle_unwritten_extents() файловой системы ext4 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-18Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09792
HIGH7.8

Уязвимость функции hci_acldata_packet() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-18Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09795
HIGH7.0

Уязвимость функции jfs_ioc_trim() файловой системы jfs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2024-11-18Modified: 2025-10-29
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-09802
MEDIUM5.5

Уязвимость компонента nl80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09804
HIGH7.8

Уязвимость компонента nft_flow_offload ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-11-19Modified: 2025-03-21
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09805
MEDIUM5.5

Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09806
MEDIUM5.5

Уязвимость компонента fbmon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09808
MEDIUM5.5

Уязвимость компонента sysv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09810
MEDIUM5.5

Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09814
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09835
MEDIUM5.5

Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09837
MEDIUM5.5

Уязвимость компонента rgb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09838
HIGH8.8

Уязвимость компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-19Modified: 2025-10-24
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09839
MEDIUM5.5

Уязвимость компонентов efi/capsule-loader ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09841
MEDIUM5.5

Уязвимость компонента supply ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09842
HIGH7.4

Уязвимость компонента rtl8xxxu ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-19Modified: 2025-08-19
CVSS 3.xHIGH 7.4
CVSS:3.x/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09845
MEDIUM5.5

Уязвимость функции tpg_alloc() в модуле drivers/media/common/v4l2-tpg/v4l2-tpg-core.c компонента v4l2-tpg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09846
MEDIUM5.5

Уязвимость компонента v4l2-mem2mem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09847
MEDIUM5.5

Уязвимость компонента imx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09848
MEDIUM5.5

Уязвимость компонента cpufreq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09849
MEDIUM5.5

Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09850
MEDIUM5.5

Уязвимость компонента dvb-frontends ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09851
MEDIUM5.5

Уязвимость компонента go7007 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09852
MEDIUM5.5

Уязвимость компонента ttpci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09853
MEDIUM5.5

Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09854
MEDIUM5.5

Уязвимость компонента hi3559a ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09856
CRITICAL9.1

Уязвимость компонента wilc1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xCRITICAL 9.1
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09857
MEDIUM5.5

Уязвимость компонентов s390/dasd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09858
MEDIUM5.5

Уязвимость компонента rtnetlink ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09859
MEDIUM5.5

Уязвимость компонента ksmbd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09861
HIGH7.0

Уязвимость функции bprm_fill_uid() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-19Modified: 2025-10-24
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2024-09866
MEDIUM5.5

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09883
MEDIUM5.5

Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09884
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09885
MEDIUM5.5

Уязвимость компонента sockmap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09886
MEDIUM5.5

Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09887
MEDIUM5.5

Уязвимость компонентов pstore/zone ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09888
MEDIUM5.5

Уязвимость компонента gro ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-19Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09892
MEDIUM5.5

Уязвимость компонента ath11k ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09893
MEDIUM5.5

Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09894
MEDIUM5.5

Уязвимость компонента send ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09895
MEDIUM5.5

Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09896
MEDIUM5.5

Уязвимость компонента iwlwifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09897
MEDIUM5.5

Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09898
MEDIUM5.5

Уязвимость компонента mlxbf_gige ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09913
MEDIUM5.5

Уязвимость компонента btintel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09915
MEDIUM5.5

Уязвимость компонента ncm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09917
MEDIUM5.5

Уязвимость компонента vt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09933
MEDIUM5.5

Уязвимость компонента udc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09938
MEDIUM5.5

Уязвимость компонента ubifs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09939
MEDIUM5.5

Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09945
MEDIUM5.5

Уязвимость компонентов drm/lima ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-20Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09961
MEDIUM5.5

Уязвимость компонента micrel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09963
MEDIUM5.5

Уязвимость компонента tls ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09964
MEDIUM5.5

Уязвимость компонента t7xx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09967
MEDIUM5.5

Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09968
MEDIUM5.5

Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09969
MEDIUM5.5

Уязвимость компонента qbman ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09971
MEDIUM5.3

Уязвимость компонента dma-buf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09972
MEDIUM6.1

Уязвимость компонента nf_tables ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-09973
MEDIUM5.5

Уязвимость компонента nci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09980
MEDIUM5.5

Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09981
MEDIUM5.5

Уязвимость компонента lis3lv02d_i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09985
LOW3.3

Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю манипулировать данными

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:N
References
BDU:2024-09988
MEDIUM5.5

Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09989
MEDIUM5.5

Уязвимость компонентов PCI/PM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09990
MEDIUM5.5

Уязвимость компонента cpumap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09991
LOW3.3

Уязвимость компонента netrom ядра операционной системы Linux, позволяющая нарушителю манипулировать данными

Published: 2024-11-21Modified: 2025-05-06
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:N
References
BDU:2024-09992
LOW3.3

Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-09993
LOW3.3

Уязвимость компонента hci_event ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-09994
MEDIUM5.5

Уязвимость компонента bridge ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-09999
MEDIUM5.5

Уязвимость компонента wilc1000 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10001
MEDIUM5.5

Уязвимость компонента hibernate ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10002
MEDIUM5.5

Уязвимость компонента init ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10004
MEDIUM5.5

Уязвимость компонента nouveau ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10008
MEDIUM5.5

Уязвимость компонента mcast ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10009
MEDIUM5.5

Уязвимость компонента SUNRPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10034
MEDIUM5.5

Уязвимость компонента tc358743 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10037
MEDIUM6.4

Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 6.4
CVSS:3.x/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10040
MEDIUM5.5

Уязвимость компонентов drm/ast ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10048
MEDIUM5.5

Уязвимость компонента erspan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10050
MEDIUM5.5

Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10052
MEDIUM5.5

Уязвимость компонента mlxbf_gige ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10053
HIGH8.8

Уязвимость компонента udp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10055
MEDIUM5.5

Уязвимость компонента dynamic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10057
MEDIUM5.5

Уязвимость компонентов mm/secretmem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10059
MEDIUM5.5

Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10061
CRITICAL9.1

Уязвимость компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xCRITICAL 9.1
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10062
HIGH8.8

Уязвимость компонентов drm/client ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-11-21Modified: 2025-05-06
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-10063
MEDIUM5.5

Уязвимость компонента dyndbg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10064
MEDIUM5.5

Уязвимость компонента VMCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10065
MEDIUM5.5

Уязвимость компонентов x86/mm/pat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-22Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10066
MEDIUM5.3

Уязвимость компонента icmp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-22Modified: 2026-01-20
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10067
LOW3.3

Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-11-22Modified: 2026-01-20
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2024-10068
MEDIUM5.5

Уязвимость компонента at24 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-22Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10069
MEDIUM5.5

Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-22Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10070
MEDIUM5.5

Уязвимость компонента ena ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-22Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10071
MEDIUM5.5

Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-22Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10072
MEDIUM5.5

Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-22Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10086
HIGH7.8

Уязвимость функции pci_bridge_wait_for_secondary_bus() драйвера шины PCI ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-11-22Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-10365
MEDIUM5.5

Уязвимость компонента compress ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-11-26Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10375
MEDIUM5.5

Уязвимость функции mmap_mutex ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность

Published: 2024-11-26Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:A/AC:L/Au:S/C:P/I:P/A:P
References
BDU:2024-10511
HIGH7.8

Уязвимость компонентов irqchip/gic-v3-its ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-02Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10512
MEDIUM5.5

Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-12-02Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-10513
MEDIUM6.3

Уязвимость компонента af_unix ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-02Modified: 2026-01-20
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10588
CRITICAL9.8

Уязвимость функции __key_instantiate_and_link() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-12-03Modified: 2025-05-06
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-10589
CRITICAL9.1

Уязвимость функций disable_show() и disable_store() драйвера USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации

Published: 2024-12-03Modified: 2025-08-19
CVSS 3.xCRITICAL 9.1
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0CRITICAL 9.4
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:C/A:C
References
BDU:2024-10601
CRITICAL9.8

Уязвимость структуры GUID файловой системы ntfs3 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-12-03Modified: 2026-01-20
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-10602
CRITICAL9.8

Уязвимость функции seg6_init() реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-12-03Modified: 2026-01-20
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-10603
CRITICAL9.8

Уязвимость функции of_modalias() ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-12-03Modified: 2026-01-20
CVSS 3.xCRITICAL 9.8
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0CRITICAL 10.0
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
References
BDU:2024-10658
LOW3.3

Уязвимость компонента n_gsm ядра операционной системы Linux, позволяющая нарушителю обойти существующие ограничения безопасности

Published: 2024-12-04Modified: 2025-10-24
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:N
References
BDU:2024-10659
MEDIUM5.5

Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10674
MEDIUM5.5

Уязвимость компонента qibfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10675
MEDIUM5.5

Уязвимость компонента phonet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10678
MEDIUM5.5

Уязвимость компонента nl80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10679
MEDIUM5.5

Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10680
MEDIUM5.5

Уязвимость компонента nfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10681
MEDIUM5.5

Уязвимость компонента xdp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10682
HIGH7.8

Уязвимость функций bnad_debugfs_write_regrd() и bnad_debugfs_write_regwr() в модуле drivers/net/ethernet/brocade/bna/bnad_debugfs.c компонента bna ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-12-04Modified: 2026-02-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-10683
MEDIUM5.5

Уязвимость компонента nsh ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10684
MEDIUM5.5

Уязвимость компонентов s390/cio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10686
MEDIUM5.5

Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10687
MEDIUM5.5

Уязвимость компонентов s390/qeth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10688
MEDIUM5.5

Уязвимость компонента bnx2fc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10690
HIGH7.8

Уязвимость функции iocg_kick_delay() в модуле block/blk-iocost.c компонента blk-iocost ядра операционной системы Linux, позволяющая нарушителю, действующему удалённо, оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2024-12-04Modified: 2026-02-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-10691
MEDIUM5.5

Уязвимость компонента kasan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10693
MEDIUM5.5

Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10694
MEDIUM5.5

Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10696
MEDIUM5.5

Уязвимость компонента sdhci-msm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10697
MEDIUM5.5

Уязвимость компонента h6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10698
MEDIUM5.5

Уязвимость компонента qla2xxx ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-12-04Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10699
HIGH7.8

Уязвимость компонента n_gsm ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2024-12-04Modified: 2026-03-04
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-10700
MEDIUM5.5

Уязвимость компонентов net/smc ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-12-04Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10701
MEDIUM5.5

Уязвимость компонентов powerpc/pseries/iommu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10704
MEDIUM5.5

Уязвимость компонента f_fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10709
MEDIUM5.5

Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10711
MEDIUM5.5

Уязвимость компонента qca ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании (DoS)

Published: 2024-12-04Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10726
MEDIUM5.5

Уязвимость компонентjd mm/hugetlb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-04Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10732
HIGH7.5

Уязвимость компонента cppc_cpufreq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2026-01-20
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10733
MEDIUM5.5

Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10734
MEDIUM5.5

Уязвимость компонента ecryptfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10735
MEDIUM5.5

Уязвимость компонента epoll ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10738
MEDIUM5.3

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-10-24
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10739
MEDIUM5.5

Уязвимость компонента libertas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10741
MEDIUM5.5

Уязвимость компонента bfa ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10742
MEDIUM4.4

Уязвимость компонента qedf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10743
MEDIUM5.5

Уязвимость компонента openvswitch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10744
MEDIUM4.4

Уязвимость компонента kirkwood ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2026-01-20
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10746
MEDIUM5.5

Уязвимость компонента cdns-mhdp8546 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10747
MEDIUM5.5

Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10749
MEDIUM5.5

Уязвимость компонента devicetree ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2024-12-05Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10751
MEDIUM5.5

Уязвимость компонента octeontx2-af ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код с повышенными привилегиями

Published: 2024-12-05Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10752
MEDIUM5.5

Уязвимость компонента tipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10754
MEDIUM4.4

Уязвимость компонента vgic-v2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10756
HIGH8.8

Уязвимость компонента lpfc ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-12-05Modified: 2025-10-24
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-10759
MEDIUM5.5

Уязвимость компонента r8169 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10761
MEDIUM5.5

Уязвимость компонента ohci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10762
HIGH7.7

Уязвимость компонента hda ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2026-01-20
CVSS 3.xHIGH 7.7
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10764
MEDIUM5.5

Уязвимость компонента carl9170 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10765
MEDIUM6.5

Уязвимость компонента ar5523 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-05Modified: 2025-05-06
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10916
MEDIUM5.5

Уязвимость компонента sock_map ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-10Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10917
MEDIUM5.5

Уязвимость компонента vmci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-10Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10920
MEDIUM5.5

Уязвимость компонента asm-bug ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-10Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10921
MEDIUM6.2

Уязвимость компонента sr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-10Modified: 2025-04-30
CVSS 3.xMEDIUM 6.2
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10930
MEDIUM5.5

Уязвимость компонентов genirq/cpuhotplug ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-10Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10932
MEDIUM5.5

Уязвимость функции cyapa_suspend() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-10Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10975
MEDIUM5.5

Уязвимость компонента libstub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-11Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10976
MEDIUM5.5

Уязвимость компонента qmi_wwan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-11Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10979
MEDIUM5.5

Уязвимость компонента ionic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-11Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-10999
MEDIUM5.5

Уязвимость компонента core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-11Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11001
MEDIUM5.5

Уязвимость компонента mpt3sas ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-11Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11002
HIGH8.8

Уязвимость компонента cachefiles ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-12-11Modified: 2025-05-06
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-11003
MEDIUM5.5

Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-11Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11004
MEDIUM5.5

Уязвимость компонентов drm/komeda ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-11Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11005
MEDIUM5.5

Уязвимость компонента liquidio ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-11Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11069
MEDIUM5.5

Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-12Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11355
MEDIUM5.5

Уязвимость компонента cdc-wdm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11356
MEDIUM4.7

Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-20Modified: 2025-05-06
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11405
MEDIUM5.5

Уязвимость функции ieee80211_sta_ps_deliver_wakeup() компонента mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-23Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11407
HIGH8.8

Уязвимость модуля fs/cachefiles/ondemand.c файловой системы cachefiles ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-23Modified: 2025-05-06
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-11521
MEDIUM5.5

Уязвимость компонента bnxt_en ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11523
MEDIUM5.5

Уязвимость компонентов mm/huge_memory ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11524
MEDIUM5.5

Уязвимость функции cfg80211_get_station() в модуле net/wireless/util.c компонента cfg80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2024-12-25Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11526
MEDIUM4.4

Уязвимость компонентов fs/9p ядра операционной системы Linux, позволяющая нарушителю читать и манипулировать данными

Published: 2024-12-25Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
CVSS 2.0LOW 3.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:P/A:N
References
BDU:2024-11542
MEDIUM5.3

Уязвимость компонента cpufreq ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-10-24
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11543
MEDIUM5.5

Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11544
HIGH8.8

Уязвимость компонентов drivers/virt/acrn ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2024-12-25Modified: 2026-01-20
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-11545
MEDIUM5.5

Уязвимость компонента m68k ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11546
MEDIUM5.5

Уязвимость компонентов macintosh/via-macii ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11547
HIGH8.8

Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2026-01-20
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11548
MEDIUM5.5

Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11549
MEDIUM5.5

Уязвимость компонента jffs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11550
MEDIUM5.5

Уязвимость компонента md ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11552
MEDIUM5.5

Уязвимость компонента sungem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11567
MEDIUM5.5

Уязвимость компонентов tools/nolibc/stdlib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11569
HIGH7.1

Уязвимость компонента rcu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11570
MEDIUM5.5

Уязвимость компонента pcie ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11575
MEDIUM5.5

Уязвимость функции io_recvmsg_mshot_prep() модуля io_uring/net.c компонентов io_uring/net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2024-11578
HIGH8.2

Уязвимость компонента carl9170 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xHIGH 8.2
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11580
MEDIUM5.5

Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-25Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11616
MEDIUM5.5

Уязвимость функции wakeup_kswapd() компонента vmscan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-26Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2024-11617
MEDIUM6.2

Уязвимость функции __lpass_get_dmactl_handle компонента qcom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-27Modified: 2025-03-21
CVSS 3.xMEDIUM 6.2
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2024-11669
MEDIUM5.5

Уязвимость функции btree_iter компонента bcache ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2024-12-31Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00021
MEDIUM5.5

Уязвимость функции remap_pfn_range_notrack() в модуле mm/memory.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-03Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00022
MEDIUM5.5

Уязвимость функции bpf_ringbuf_reserve() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-03Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00023
MEDIUM4.4

Уязвимость функции stream_enc_regs() подсистемы Direct Rendering Manager (DRM) ядра операционной системы Linux ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-03Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00024
MEDIUM4.7

Уязвимость компонента Netfilter ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии

Published: 2025-01-03Modified: 2025-08-19
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-00026
HIGH7.8

Уязвимость функции rcu_nocb_bypass_lock механизма синхронизации Read-copy-update (RCU) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-03Modified: 2025-03-21
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-00133
HIGH7.0

Уязвимость функции kunit_try_catch_run() фреймворка KUnit (lib/kunit/try-catch.c) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-01-10Modified: 2025-05-06
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2025-00151
HIGH7.5

Уязвимость функции hci_user_confirm_request_evt() в модуле net/bluetooth/hci_event.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность защищаемой информации

Published: 2025-01-13Modified: 2025-09-05
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:N/A:N
References
BDU:2025-00776
MEDIUM5.5

Уязвимость компонента drivers/net/dsa/mv88e6xxx/global1_atu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00839
MEDIUM5.5

Уязвимость функции nv17_tv_get_ld_modes() модуля drivers/gpu/drm/nouveau/dispnv04/tvnv17.c драйвера DRM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-28Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00872
MEDIUM5.5

Уязвимость функции fsl_asoc_card_probe() (sound/soc/fsl/fsl-asoc-card.c) компонента AsoC ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-29Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00879
MEDIUM5.5

Уязвимость функции davinci_gpio_probe() компонента gpio ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-29Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00881
MEDIUM5.5

Уязвимость функции btrfs_quota_disable() компонента btrfs ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-29Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00882
MEDIUM5.5

Уязвимость функции ila_output() компонента ila ядра операционных систем Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-29Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00885
MEDIUM5.5

Уязвимость функции nv17_tv_get_hd_modes() драйвера DRM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-29Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00922
HIGH7.1

Уязвимость функции br_dev_xmit() в модуле net/bridge/br_device.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2025-01-31Modified: 2025-08-19
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-00926
MEDIUM4.4

Уязвимость функции i915_gem_object_is_shrinkable() драйвера DRM (drivers/gpu/drm/i915/gem/i915_gem_object.h) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-31Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-00933
MEDIUM5.5

Уязвимость функции nilfs_segctor_prepare_write() в модуле fs/nilfs2/segment.c файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-31Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00935
MEDIUM5.5

Уязвимость функции me_huge_page() модуля mm/memory-failure.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-31Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00937
MEDIUM5.5

Уязвимость функции rt6_probe() модуля net/ipv6/route.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-01-31Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00981
MEDIUM5.5

Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00982
MEDIUM5.2

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.2
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:H/Au:M/C:P/I:P/A:C
References
BDU:2025-00983
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00984
MEDIUM4.1

Уязвимость компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-05-06
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-00985
MEDIUM5.1

Уязвимость компонента x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.1
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-00986
MEDIUM5.5

Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00987
MEDIUM4.1

Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-00989
MEDIUM5.5

Уязвимость компонентов drm/nouveau ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00992
MEDIUM5.8

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.8
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:L/AC:H/Au:S/C:P/I:P/A:C
References
BDU:2025-00993
MEDIUM4.4

Уязвимость компонента inet_diag ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-05-06
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-00994
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00996
MEDIUM4.4

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-08-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-00997
MEDIUM5.5

Уязвимость компонента jffs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-00998
MEDIUM5.2

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.2
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 4.4
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:P/A:C
References
BDU:2025-00999
MEDIUM5.5

Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01000
MEDIUM4.4

Уязвимость компонента powerpc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-01001
MEDIUM4.4

Уязвимость компонентов drm/lima ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-01003
MEDIUM4.4

Уязвимость компонента mm ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-01006
HIGH7.8

Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-01007
MEDIUM5.5

Уязвимость компонента riscv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01035
MEDIUM5.5

Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-02-03Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01046
MEDIUM5.5

Уязвимость компонента dw-axi-dmac ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01047
MEDIUM5.3

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 4.5
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:P/A:C
References
BDU:2025-01048
MEDIUM6.6

Уязвимость компонентов powerpc/pseries ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 6.6
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 5.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:P/A:C
References
BDU:2025-01049
MEDIUM5.5

Уязвимость компонентов drm/lima ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01050
MEDIUM5.5

Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01051
MEDIUM5.5

Уязвимость компонента drop_monitor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01052
MEDIUM5.5

Уязвимость компонента batman-adv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01053
MEDIUM5.5

Уязвимость компонента tipc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01054
MEDIUM5.5

Уязвимость компонента ACPICA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01055
MEDIUM6.1

Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:C
References
BDU:2025-01056
MEDIUM6.1

Уязвимость компонентов drm/radeon ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:C
References
BDU:2025-01057
MEDIUM4.7

Уязвимость компонентов RDMA/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-04-30
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01060
MEDIUM5.5

Уязвимость компонентов net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01061
MEDIUM5.5

Уязвимость компонента crypto ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01062
MEDIUM5.5

Уязвимость компонента tracing ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01063
MEDIUM5.5

Уязвимость компонента netrom ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01064
LOW3.3

Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2026-03-04
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-01091
MEDIUM5.5

Уязвимость компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01230
LOW2.5

Уязвимость модуля nf_tables компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-06Modified: 2025-05-06
CVSS 3.xLOW 2.5
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.0
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:P
References
BDU:2025-01322
LOW1.9

Уязвимость функции i40e_xdp_setup() (drivers/net/ethernet/intel/i40e/i40e_main.c) драйвера i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2026-01-20
CVSS 3.xLOW 1.9
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 0.8
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:P
References
BDU:2025-01332
MEDIUM4.1

Уязвимость функций ppp_read() и ppp_write() (drivers/net/ppp/ppp_generic.c) драйвера ppp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-05-06
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-01333
MEDIUM4.1

Уязвимость функций nf_tables_rule_release(), nft_chain_validate(), nft_chain_validate_hooks() и nft_validate_register_store() (net/netfilter/nf_tables_api.c) компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-08-19
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-01334
MEDIUM5.5

Уязвимость функция sock_set_flag() и spin_unlock() (net/ipv4/udp.c) компонента udp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01335
MEDIUM5.5

Уязвимость функций cs_dsp_coeff_parse_string(), cs_dsp_coeff_parse_int(), cs_dsp_coeff_parse_coeff() и cs_dsp_parse_coeff() (drivers/firmware/cirrus/cs_dsp.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01336
MEDIUM5.5

Уязвимость функции usb_parse_endpoint() (drivers/usb/core/config.c) драйвера USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01337
MEDIUM5.5

Уязвимость функции nilfs_dotdot() файловой системы nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01338
MEDIUM4.4

Уязвимость драйвера toshiba_acpi (drivers/platform/x86/toshiba_acpi.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-05-06
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-01339
LOW1.9

Уязвимость функции sclp_init() (drivers/s390/char/sclp.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-10-24
CVSS 3.xLOW 1.9
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 0.8
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:P
References
BDU:2025-01340
MEDIUM4.4

Уязвимость функции alloc_dispatch_log_kmem_cache() (arch/powerpc/platforms/pseries/setup.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-01341
MEDIUM5.5

Уязвимость функции hci_unregister_dev() (net/bluetooth/hci_core.c) драйвера Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01342
MEDIUM5.5

Уязвимость функции radeon_gem_va_update_vm() (drivers/gpu/drm/radeon/radeon_gem.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-10Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01404
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01406
MEDIUM5.1

Уязвимость компонента amdtp-stream ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2026-01-20
CVSS 3.xMEDIUM 5.1
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:L/AC:L/Au:M/C:P/I:N/A:C
References
BDU:2025-01407
MEDIUM5.5

Уязвимость компонента nvme-pci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01411
MEDIUM5.5

Уязвимость компонентов riscv/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01412
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01416
MEDIUM5.5

Уязвимость компонентов drm/i915/gem ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01417
MEDIUM5.5

Уязвимость компонента apparmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01419
MEDIUM5.5

Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01420
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01421
MEDIUM5.5

Уязвимость компонента udf ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01423
MEDIUM5.5

Уязвимость компонентов drm/gma500 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01424
MEDIUM5.1

Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.1
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:L/AC:L/Au:M/C:P/I:N/A:C
References
BDU:2025-01425
MEDIUM5.5

Уязвимость компонентов IB/core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01426
MEDIUM4.7

Уязвимость компонента nvmet ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-01427
MEDIUM5.5

Уязвимость компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01429
MEDIUM5.5

Уязвимость компонента sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01430
MEDIUM5.5

Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01431
MEDIUM5.5

Уязвимость компонентов drm/gma500 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01432
MEDIUM5.5

Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01434
MEDIUM5.5

Уязвимость компонентов fs/file ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01436
MEDIUM5.5

Уязвимость компонента fair ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01437
MEDIUM5.5

Уязвимость компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01444
MEDIUM5.5

Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01445
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01446
MEDIUM5.5

Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01447
MEDIUM4.7

Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01448
MEDIUM5.5

Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю повысить привилегии

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01449
MEDIUM5.5

Уязвимость компонента scsi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01450
MEDIUM5.5

Уязвимость компонентов irqchip/imx-irqsteer ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01451
MEDIUM5.5

Уязвимость компонента kobject_uevent ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01453
MEDIUM5.1

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.1
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:L/AC:L/Au:M/C:P/I:N/A:C
References
BDU:2025-01454
MEDIUM5.1

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.1
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:H
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:L/AC:L/Au:M/C:P/I:N/A:C
References
BDU:2025-01455
MEDIUM5.5

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:L/AC:L/Au:M/C:P/I:N/A:C
References
BDU:2025-01457
MEDIUM5.5

Уязвимость компонентов fs/ntfs3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-12Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01469
MEDIUM5.2

Уязвимость функций cs_dsp_coeff_parse_alg() и cs_dsp_coeff_parse_coeff() (drivers/firmware/cirrus/cs_dsp.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.2
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:H/Au:M/C:P/I:P/A:C
References
BDU:2025-01470
MEDIUM5.5

Уязвимость функции pfn_section_valid() модуля include/linux/mmzone.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01572
MEDIUM4.7

Уязвимость функции cachefiles_ondemand_send_req() (fs/cachefiles/ondemand.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-14Modified: 2025-04-30
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01573
MEDIUM5.5

Уязвимость функции sk_msg_recvmsg() (net/core/skmsg.c) компонента skmsg ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-14Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-01574
MEDIUM5.5

Уязвимость функции eeh_pe_bus_get() (arch/powerpc/kernel/eeh_pe.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-14Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01575
NONE

Уязвимость функции userfaultfd_api() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-14Modified: 2025-04-30
CVSS 3.x
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N
CVSS 2.0
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:N
References
BDU:2025-01651
MEDIUM5.5

Уязвимость компонента staging ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01652
MEDIUM5.5

Уязвимость компонента i3c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01653
MEDIUM5.5

Уязвимость компонента spi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01654
MEDIUM5.5

Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01655
MEDIUM5.5

Уязвимость компонента rtmutex ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01656
HIGH7.8

Уязвимость компонента sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-01657
MEDIUM5.5

Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01658
MEDIUM5.5

Уязвимость компонентов drm/bridge ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01659
MEDIUM5.5

Уязвимость компонентов drm/amd/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01660
MEDIUM5.5

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01661
MEDIUM5.5

Уязвимость компонента can ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01662
MEDIUM5.5

Уязвимость компонента udf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01663
MEDIUM5.5

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01665
MEDIUM5.5

Уязвимость компонента fou ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01666
MEDIUM5.5

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01667
HIGH7.1

Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01668
MEDIUM5.5

Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01669
MEDIUM5.5

Уязвимость компонента arm64 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01670
MEDIUM4.7

Уязвимость компонента fsnotify ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01671
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01672
HIGH7.8

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-01673
MEDIUM5.5

Уязвимость компонентов pci/hotplug/pnv_php ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01674
MEDIUM5.5

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01676
MEDIUM5.5

Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01677
MEDIUM5.5

Уязвимость компонента MIPS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01678
MEDIUM4.7

Уязвимость компонентов lib/generic-radix-tree.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01703
MEDIUM5.5

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01714
MEDIUM5.5

Уязвимость компонентов drm/vmwgfx ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2026-03-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01715
MEDIUM5.5

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01716
MEDIUM5.5

Уязвимость компонента md ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01717
MEDIUM5.5

Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01718
MEDIUM5.5

Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01721
MEDIUM5.5

Уязвимость компонента lib ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01722
MEDIUM5.5

Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01723
MEDIUM5.5

Уязвимость компонента xdp ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-02-18Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01724
MEDIUM5.5

Уязвимость компонента leds ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01725
MEDIUM5.5

Уязвимость компонентов drm/qxl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01726
MEDIUM5.5

Уязвимость компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01727
MEDIUM5.5

Уязвимость компонента AsoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01728
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01729
MEDIUM5.5

Уязвимость компонентов mm/mglru ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01730
MEDIUM5.5

Уязвимость компонента sysctl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01731
MEDIUM5.5

Уязвимость компонента perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01732
MEDIUM5.5

Уязвимость компонентов drm/nouveau ядра операционной системы Linux, позволяющая нарушителю выполнить произвольный код

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01733
MEDIUM5.5

Уязвимость компонента remoteproc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01734
MEDIUM5.5

Уязвимость компонента dma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01735
MEDIUM5.5

Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01736
MEDIUM5.5

Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01737
LOW3.3

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-04-30
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:N
References
BDU:2025-01738
HIGH7.8

Уязвимость компонента bna ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01739
MEDIUM5.5

Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01744
MEDIUM5.5

Уязвимость компонента uio_hv_generic ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01745
MEDIUM5.5

Уязвимость компонента ublk_drv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01747
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01750
MEDIUM5.5

Уязвимость компонента apparmor ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01751
MEDIUM4.7

Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01752
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01763
MEDIUM5.5

Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01765
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01766
MEDIUM5.5

Уязвимость компонента soc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01767
MEDIUM5.5

Уязвимость компонентов smb/client ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01768
MEDIUM5.5

Уязвимость компонента pinctrl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01769
MEDIUM4.7

Уязвимость компонента ethtool ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01770
MEDIUM5.5

Уязвимость компонента gtp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-18Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01782
MEDIUM5.5

Уязвимость компонента mmc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01783
MEDIUM5.5

Уязвимость функции close_range() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-19Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01784
MEDIUM5.5

Уязвимость функции memcg_write_event_control() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01786
MEDIUM5.5

Уязвимость компонентов net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01805
MEDIUM5.5

Уязвимость компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-19Modified: 2025-05-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01806
MEDIUM5.5

Уязвимость функции input_mt_init_slots() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-19Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01807
MEDIUM5.5

Уязвимость компонентов rtla/osnoise ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-19Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01854
MEDIUM5.5

Уязвимость функций input_action_end_dx4() и input_action_end_dx6() модуля net/ipv6/seg6_local.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-02-20Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01905
MEDIUM5.5

Уязвимость компонента bonding ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01906
MEDIUM5.5

Уязвимость компонентов drm/msm/dpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01907
MEDIUM5.5

Уязвимость компонентов s390/sclp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01908
MEDIUM5.5

Уязвимость компонента binfmt_flat ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01909
MEDIUM5.5

Уязвимость компонентов x86/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01910
MEDIUM5.5

Уязвимость компонентов sched/smt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01911
MEDIUM4.7

Уязвимость компонента ALSA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01913
MEDIUM5.5

Уязвимость компонента sctp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01914
MEDIUM5.5

Уязвимость компонентов md/raid ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01915
MEDIUM5.5

Уязвимость компонентов drm/amdgpu/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01916
MEDIUM5.5

Уязвимость компонента char ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01917
MEDIUM5.5

Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01919
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01920
MEDIUM5.5

Уязвимость компонентов drm/amdgpu ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01921
MEDIUM5.5

Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01922
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01923
MEDIUM5.5

Уязвимость компонентов drm/client ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01924
MEDIUM4.7

Уязвимость компонента memcg ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-02-24Modified: 2025-10-29
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01926
MEDIUM5.5

Уязвимость компонента tracing ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01927
MEDIUM5.5

Уязвимость компонента padata ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01930
MEDIUM5.5

Уязвимость компонента mlxsw ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01931
MEDIUM5.5

Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01932
MEDIUM5.5

Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01933
MEDIUM5.5

Уязвимость компонента devres ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01934
MEDIUM5.5

Уязвимость компонента perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01935
MEDIUM5.5

Уязвимость компонента Input ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01938
MEDIUM5.5

Уязвимость компонента thunderbolt ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01942
MEDIUM5.5

Уязвимость компонента nfc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01943
MEDIUM5.5

Уязвимость компонента netem ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01944
MEDIUM5.5

Уязвимость компонента i2c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01945
MEDIUM5.5

Уязвимость компонента xhci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01947
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01948
MEDIUM5.5

Уязвимость компонента bonding ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01950
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01953
HIGH7.8

Уязвимость компонентов drm/mgag200 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-01954
MEDIUM5.5

Уязвимость компонентов x86/mtrr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-01955
MEDIUM5.5

Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-01956
HIGH7.8

Уязвимость компонента char ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01957
MEDIUM5.5

Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01963
MEDIUM5.5

Уязвимость компонентов fs/netfs/fscache_cookie ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01964
MEDIUM5.5

Уязвимость компонентов drm/amdgpu/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01965
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01968
MEDIUM5.5

Уязвимость компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01971
MEDIUM5.5

Уязвимость компонента usb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01972
MEDIUM5.5

Уязвимость компонента PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01973
MEDIUM5.5

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01977
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-01983
MEDIUM5.5

Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02069
MEDIUM5.5

Уязвимость функций amdgpu_vkms_prepare_fb() и amdgpu_vkms_cleanup_fb() (drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-26Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02071
MEDIUM5.5

Уязвимость функции dev_kfree_skb_any() (drivers/net/ethernet/google/gve/gve_rx_dqo.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-26Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02074
MEDIUM4.4

Уязвимость функции __cvmx_pcie_build_config_addr() компонента mips ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-02-26Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-02530
MEDIUM6.6

Уязвимость функций rdma_restrack_init() и type2str() драйвера Infiniband (drivers/infiniband/core/restrack.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-10-24
CVSS 3.xMEDIUM 6.6
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 6.1
CVSS:2.0/AV:L/AC:L/Au:N/C:P/I:P/A:C
References
BDU:2025-02531
MEDIUM5.5

Уязвимость функции cfg80211_wext_siwscan() (net/wireless/scan.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02532
MEDIUM4.4

Уязвимость функции null_validate_conf() (drivers/block/null_blk/main.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-02533
MEDIUM5.5

Уязвимость функции create_pinctrl() (drivers/pinctrl/core.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02534
LOW3.3

Уязвимость функции j1939_xtp_rx_rts_session_new() (net/can/j1939/transport.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-05-06
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-02535
MEDIUM5.5

Уязвимость функций nft_lookup_init(), nf_tables_fill_setelem() и nft_validate_register_store() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02536
MEDIUM5.5

Уязвимость функции ata_host_release() драйвера портов ATA (drivers/ata/libata-core.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02538
MEDIUM5.5

Уязвимость функции __xdp_reg_mem_model() (net/core/xdp.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02539
MEDIUM5.5

Уязвимость функции cxacru_bind() драйвера USB (drivers/usb/atm/cxacru.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02541
MEDIUM5.5

Уязвимость функций MODULE_ALIAS() и j1939_send_one() (net/can/j1939/main.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02549
MEDIUM5.7

Уязвимость функции ftruncate() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-08-19
CVSS 3.xMEDIUM 5.7
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N
CVSS 2.0MEDIUM 5.3
CVSS:2.0/AV:L/AC:H/Au:M/C:C/I:C/A:N
References
BDU:2025-02552
MEDIUM5.5

Уязвимость функций ocfs2_extend_trans() и ocfs2_dio_end_io_write() кластерной файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02553
MEDIUM5.3

Уязвимость функций bme680_compensate_temp(), bme680_compensate_press() и bme680_compensate_humid() драйвера IIO (drivers/iio/chemical/bme680_core.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-05-06
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:C
References
BDU:2025-02554
MEDIUM5.5

Уязвимость функций dwc3_suspend_common() и dwc3_resume_common() драйвера USB (drivers/usb/dwc3/core.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02555
LOW2.3

Уязвимость функций ili9881c_prepare() и ili9881c_unprepare() драйвера (drivers/gpu/drm/panel/panel-ilitek-ili9881c.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-12Modified: 2025-10-24
CVSS 3.xLOW 2.3
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.4
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:P
References
BDU:2025-02904
MEDIUM5.5

Уязвимость функции axg_clk_regmaps{} модуля drivers/clk/meson/axg.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-19Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02907
MEDIUM5.5

Уязвимость функции hci_get_dev_info() модуля net/bluetooth/hci_core.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-19Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02909
MEDIUM5.5

Уязвимость функции fcoe_ctlr_announce() модуля drivers/scsi/fcoe/fcoe_ctlr.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-19Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02910
MEDIUM5.5

Уязвимость функции cik_ih_get_wptr() модуля drivers/gpu/drm/amd/amdgpu/cik_ih.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-19Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02911
MEDIUM5.5

Уязвимость функции pmu_sbi_set_scounteren() модуля drivers/perf/riscv_pmu_sbi.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-19Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02920
MEDIUM5.5

Уязвимость функции mtk_clk_simple_probe() модуля drivers/clk/mediatek/clk-mtk.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-19Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02925
MEDIUM5.5

Уязвимость функции amdgpu_dm_fini() модуля drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-19Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02927
MEDIUM5.5

Уязвимость функции gpiochip_get_desc() модуля drivers/gpio/gpiolib.c драйвера GPIO ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации

Published: 2025-03-19Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02928
MEDIUM5.5

Уязвимость функции mlx5e_arfs_enable() модуля drivers/net/ethernet/mellanox/mlx5/core/en_arfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-19Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02943
MEDIUM5.5

Уязвимость функции instance_destroy_rcu() модуля net/netfilter/nfnetlink_queue.c компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02944
MEDIUM5.5

Уязвимость функции nf_tproxy_laddr4() модуля net/ipv4/netfilter/nf_tproxy_ipv4.c реализации протокола IPv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02945
MEDIUM5.5

Уязвимость функции svdm_consume_identity() модуля drivers/usb/typec/tcpm/tcpm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02946
MEDIUM5.5

Уязвимость функции tls_ctx_create() модуля net/tls/tls_main.c реализации протокола TLS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02948
MEDIUM5.5

Уязвимость функции free_ep_fback() модуля drivers/usb/gadget/function/u_audio.c драйвера USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02949
MEDIUM5.5

Уязвимость функции bpf_ctx_narrow_access_offset() модуля include/linux/filter.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02959
MEDIUM5.5

Уязвимость функции disable_hpo_dp_link_output() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02962
MEDIUM5.5

Уязвимость функции ks_pcie_setup_rc_app_regs() модуля drivers/pci/controller/dwc/pci-keystone.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02966
MEDIUM5.5

Уязвимость функции is_dsc_need_re_compute() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02969
MEDIUM5.5

Уязвимость функции ip_cmsg_recv() ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации

Published: 2025-03-20Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2025-02970
MEDIUM5.5

Уязвимость функции dasd_copy_pair_store() модуля drivers/s390/block/dasd_devmap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-20Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02979
MEDIUM5.5

Уязвимость функции lvts_probe() модуля drivers/thermal/mediatek/lvts_thermal.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02989
MEDIUM5.5

Уязвимость функции __vhost_worker_flush() модуля drivers/vhost/vhost.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02997
MEDIUM5.5

Уязвимость функции snd_acp_resume() модуля sound/soc/amd/acp/acp-pci.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-02998
MEDIUM5.5

Уязвимость функции gfs2_jindex_free() модуля fs/gfs2/super.c файловой системы GFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-02999
MEDIUM5.5

Уязвимость функции add_adev() модуля drivers/net/ethernet/microsoft/mana/mana_en.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03000
MEDIUM5.5

Уязвимость функции bpf_int_jit_compile() модуля arch/arm/net/bpf_jit_32.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03003
MEDIUM5.5

Уязвимость функции PROG_NAME() модуля kernel/bpf/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03005
MEDIUM5.5

Уязвимость функции mcp251xfd_open() модуля drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03011
MEDIUM5.5

Уязвимость функции nfs4_set_security_label() модуля fs/nfs/nfs4proc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03013
MEDIUM5.5

Уязвимость функции ibmvnic_xmit() модуля drivers/net/ethernet/ibm/ibmvnic.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03018
MEDIUM5.5

Уязвимость функции ks8851_irq() модуля drivers/net/ethernet/micrel/ks8851_common.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03021
MEDIUM5.5

Уязвимость функции amd_pstate_epp_cpu_exit() модуля drivers/cpufreq/amd-pstate.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03022
MEDIUM5.5

Уязвимость функции mt7921_mac_reset_work() модуля drivers/net/wireless/mediatek/mt76/mt7921/mac.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03023
MEDIUM5.5

Уязвимость функции mtk_vcodec_fw_scp_init() модуля drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_scp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03024
MEDIUM5.5

Уязвимость функции ext4_xattr_set_entry() модуля fs/ext4/xattr.c файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03027
MEDIUM5.5

Уязвимость функции iommu_aux_get_pasid() модуля include/linux/iommu.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03028
MEDIUM5.5

Уязвимость функции ax25_accept() модуля net/ax25/af_ax25.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03029
MEDIUM5.5

Уязвимость функции f2fs_handle_critical_error() модуля fs/f2fs/super.c файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03031
HIGH7.1

Уязвимость функции ep93xx_div_recalc_rate() модуля arch/arm/mach-ep93xx/clock.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-03032
MEDIUM5.5

Уязвимость функции max3100_probe() модуля drivers/tty/serial/max3100.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03033
MEDIUM5.5

Уязвимость функции lmh_probe() модуля drivers/thermal/qcom/lmh.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03034
HIGH7.8

Уязвимость функции init_conns() драйвера drivers/infiniband/ulp/rtrs/rtrs-clt.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03035
MEDIUM5.5

Уязвимость функции p9_fcall_init() модуля net/9p/client.c реализации протокола 9P ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03038
HIGH7.8

Уязвимость функции struct buffer_head *ext4_find_inline_entry() модуля fs/ext4/inline.c ядра операционной системы Linux позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-21Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03039
HIGH7.8

Уязвимость функции rtw_wait_firmware_completion() модуля drivers/net/wireless/realtek/rtw88/main.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03041
MEDIUM5.5

Уязвимость функции ax25_addr_ax25dev() модуля net/ax25/ax25_dev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03042
MEDIUM5.5

Уязвимость функции gem_interrupt() модуля drivers/net/ethernet/sun/sungem.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03044
MEDIUM5.5

Уязвимость функции ntfs_get_block_vbo() модуля fs/ntfs3/inode.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03046
MEDIUM5.5

Уязвимость функции mlx5_eswitch_offloads_single_fdb_add_one() модуля drivers/net/ethernet/mellanox/mlx5/core/eswitch.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03047
MEDIUM5.5

Уязвимость функции ax25_dev_device_down() модуля net/ax25/ax25_dev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03048
MEDIUM5.5

Уязвимость функции fec_set_mac_address() модуля drivers/net/ethernet/freescale/fec_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03049
MEDIUM5.5

Уязвимость функции dmirror_device_evict_chunk() модуля lib/test_hmm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03050
MEDIUM5.5

Уязвимость функции a6xx_gpu_init() модуля drivers/gpu/drm/msm/adreno/a6xx_gpu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03051
MEDIUM5.5

Уязвимость функции fpga_mgr_register() модуля Documentation/driver-api/fpga/fpga-mgr.rst ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03052
MEDIUM5.5

Уязвимость функции lpfc_els_retry_delay() модуля drivers/scsi/lpfc/lpfc_els.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-12-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03055
MEDIUM5.5

Уязвимость функции userfaultfd_release() модуля fs/userfaultfd.c файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03056
MEDIUM5.5

Уязвимость функции fpga_bridge_register() модуля Documentation/driver-api/fpga/fpga-bridge.rst ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03058
MEDIUM5.5

Уязвимость функции __ip6_make_skb() модуля net/ipv6/ip6_output.c реализации протокола IPv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03062
MEDIUM5.5

Уязвимость функции cifs_pick_channel() модуля fs/smb/client/transport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03064
MEDIUM5.5

Уязвимость функции perf_event_cpu_offline() модуля drivers/dma/idxd/perfmon.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03065
MEDIUM5.5

Уязвимость функции cifs_sync_mid_result() модуля fs/smb/client/transport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03066
MEDIUM5.5

Уязвимость функции comphy_gbe_phy_init() модуля drivers/phy/marvell/phy-mvebu-a3700-comphy.c драйвера PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03067
MEDIUM5.5

Уязвимость функции mlxsw_sp_acl_tcam_vregion_rehash_work() модуля drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03068
MEDIUM5.5

Уязвимость функции tusb1210_remove_charger_detect() модуля drivers/phy/ti/phy-tusb1210.c драйвера PHY ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03071
MEDIUM5.5

Уязвимость функции virtnet_get_rxfh() модуля drivers/net/virtio_net.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03074
MEDIUM5.5

Уязвимость функции geneve_xmit_skb() модуля drivers/net/geneve.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03075
MEDIUM5.5

Уязвимость функции bnxt_rdma_aux_device_init() модуля drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03077
MEDIUM5.5

Уязвимость функции rtw89_ops_bss_info_changed() модуля drivers/net/wireless/realtek/rtw89/mac80211.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03082
MEDIUM5.5

Уязвимость функции init_sel_fs() модуля security/selinux/selinuxfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03083
MEDIUM5.5

Уязвимость функции phy_sfp_probe() модуля drivers/net/phy/phy_device.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03084
MEDIUM5.5

Уязвимость функции fiemap_process_hole() модуля fs/btrfs/extent_io.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03085
MEDIUM5.5

Уязвимость функции bq27xxx_battery_i2c_remove() модуля drivers/power/supply/bq27xxx_battery_i2c.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03086
MEDIUM5.5

Уязвимость функции nvkm_client_new() модуля drivers/gpu/drm/nouveau/nvkm/core/client.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03087
MEDIUM5.5

Уязвимость функции usbtv_video_free() модуля drivers/media/usb/usbtv/usbtv-video.c драйвера USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03088
MEDIUM5.5

Уязвимость функции nvme_alloc_admin_tag_set() модуля drivers/nvme/host/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03095
MEDIUM5.5

Уязвимость функции ta_if_invoke_debugfs_write() модуля drivers/gpu/drm/amd/amdgpu/amdgpu_psp_ta.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03097
MEDIUM5.5

Уязвимость функции __nl80211_set_channel() модуля net/wireless/nl80211.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-21Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03107
HIGH7.1

Уязвимость функции dbMount() модуля fs/jfs/jfs_dmap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-03108
HIGH7.8

Уязвимость функции qm_soft_reset_prepare() модуля drivers/crypto/hisilicon/qm.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03109
HIGH7.8

Уязвимость функции _request_firmware() модуля drivers/base/firmware_loader/main.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-24Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-03110
HIGH7.8

Уязвимость функции vhost_vdpa_vring_ioctl() модуля drivers/vhost/vdpa.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-03-24Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03111
MEDIUM5.5

Уязвимость функций calculate_ttu_cursor(), calculate_ttu_cursor() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03112
MEDIUM5.5

Уязвимость функции init_overdrive_limits() в модуле drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03113
MEDIUM5.5

Уязвимость функций get_ext_path(), ext4_find_extent() и ext4_split_extent_at() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03114
HIGH7.1

Уязвимость функции acpi_device_setup_files() модуля drivers/acpi/device_sysfs.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-03115
HIGH7.8

Уязвимость функции cm_helper_translate_curve_to_degamma_hw_format() модуля drivers/gpu/drm/amd/display/dc/dcn10/dcn10_cm_common.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03116
MEDIUM5.5

Уязвимость функции btrfs_update_reloc_root() (fs/btrfs/relocation.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03117
MEDIUM5.5

Уязвимость функции efi_retrieve_tpm2_eventlog() (drivers/firmware/efi/libstub/tpm.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03118
HIGH7.8

Уязвимость функции cm3_helper_translate_curve_to_degamma_hw_format() модуля drivers/gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-03-24Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03119
MEDIUM5.5

Уязвимость функции __sgx_alloc_epc_page() (arch/x86/kernel/cpu/sgx/main.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03120
HIGH7.1

Уязвимость функции ea_get() модуля fs/jfs/xattr.c ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к защищаемой информации.

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-03121
MEDIUM5.5

Уязвимость функции dc_allow_idle_optimizations() модуля drivers/gpu/drm/amd/display/dc/core/dc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03123
MEDIUM5.5

Уязвимость функции bpf_core_apply() (kernel/bpf/btf.c) компонента BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03125
MEDIUM5.5

Уязвимость функции EXPORT_SYMBOL_GPL() (kernel/resource.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03126
MEDIUM5.5

Уязвимость функции close_ctree() (fs/btrfs/disk-io.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03128
MEDIUM5.5

Уязвимость функции vhost_scsi_get_req() (drivers/vhost/scsi.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03129
MEDIUM5.5

Уязвимость функции osnoise_hotplug_workfn() (kernel/trace/trace_osnoise.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03132
HIGH7.8

Уязвимость функций tpm2_flush_space(), tpm_dev_transmit() драйвера Trusted Platform Module (TPM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03133
MEDIUM5.5

Уязвимость функции commit_planes_for_stream() модуля drivers/gpu/drm/amd/display/dc/core/dc.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03144
MEDIUM5.5

Уязвимость функций dbAdjTree() и dbFindLeaf() модуля fs/jfs/jfs_dmap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03145
MEDIUM5.5

Уязвимость функции are_stream_backends_same() модуля drivers/gpu/drm/amd/display/dc/core/dc_resource.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03146
MEDIUM5.5

Уязвимость функции _isst_if_get_pci_dev() (drivers/platform/x86/intel/speed_select_if/isst_if_common.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03147
MEDIUM5.5

Уязвимость функций cachefiles_open_file(), fput() и cachefiles_look_up_object() компонента CacheFiles ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03148
MEDIUM5.5

Уязвимость функции ocfs2_set_buffer_uptodate() кластерной файловой системы OCFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03149
MEDIUM5.5

Уязвимость демона nfsd модуля fs/nfsd/vfs.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03150
MEDIUM5.5

Уязвимость функций adp5589_keypad_add() и adp5589_probe() драйвера ADP5589 (drivers/input/keyboard/adp5589-keys.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03151
MEDIUM5.5

Уязвимость функций omapdrm_init() и omap_gem_deinit() драйвера DRM (drivers/gpu/drm/omapdrm/omap_drv.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03152
MEDIUM5.5

Уязвимость функции dbDiscardAG() файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03153
MEDIUM5.5

Уязвимость функции dtInsert() файловой системы JFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-24Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03200
MEDIUM5.5

Уязвимость функции hex2bitmap() модуля drivers/s390/crypto/ap_bus.c - драйвера поддержки криптографии на платформе S390 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-25Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03222
MEDIUM5.5

Уязвимость функции pm8001_phy_control() драйвера SCSI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-26Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03226
MEDIUM5.5

Уязвимость функции mt7921_ipv6_addr_change() драйвера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-26Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03254
MEDIUM5.5

Уязвимость функции mlx5_eswitch_set_vepa() драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-26Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03256
MEDIUM5.5

Уязвимость функции load_elf_binary() файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-26Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03257
MEDIUM5.5

Уязвимость функции aqua_vanjaram_switch_partition_mode() драйвера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-26Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03277
MEDIUM5.5

Уязвимость компонентов RDMA/cxgb4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03282
MEDIUM6.3

Уязвимость функции rxe_comp_queue_pkt() модуля drivers/infiniband/sw/rxe/rxe_comp.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании.

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:C/A:C
References
BDU:2025-03284
MEDIUM6.5

Уязвимость функции ib_cache_setup_one() модуля drivers/infiniband/core/cache.c - драйвера поддержки InfiniBand ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03285
MEDIUM6.5

Уязвимость функции __cld_pipe_inprogress_downcall() модуля fs/nfsd/nfs4recover.c поддержки сетевой файловой системы NFS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03288
MEDIUM5.5

Уязвимость компонента bpf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03289
MEDIUM5.5

Уязвимость компонентов block, bfq ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03290
MEDIUM5.5

Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03293
MEDIUM5.5

Уязвимость компонента WiFi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03294
MEDIUM5.5

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03295
MEDIUM5.5

Уязвимость компонента sock_map ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03297
MEDIUM5.5

Уязвимость компонента tcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03300
MEDIUM5.5

Уязвимость компонента USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2025-03379
MEDIUM5.5

Уязвимость компонента Landlock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:A/AC:L/Au:S/C:P/I:P/A:P
References
BDU:2025-03386
HIGH7.8

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-03387
MEDIUM5.5

Уязвимость компонента KEYS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03390
MEDIUM5.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-12-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03391
MEDIUM5.5

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03392
MEDIUM4.4

Уязвимость компонентов selinux и smack ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:C/A:N
References
BDU:2025-03395
MEDIUM5.5

Уязвимость компонента nfsd ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03396
MEDIUM5.5

Уязвимость компонента padata ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03397
MEDIUM5.5

Уязвимость функции mptcp_stream_connect() компонента mptcp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03398
MEDIUM5.5

Уязвимость функции cachefiles_daemon_open() компонента cachefiles ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03400
MEDIUM4.4

Уязвимость функции ipc_devlink_create_region() компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-03401
MEDIUM4.4

Уязвимость функции mlx5_lag_create_port_sel_table() компонентов net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-03402
MEDIUM4.1

Уязвимость функции iwl_mvm_mfu_assert_dump_notif() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-08-19
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-03403
MEDIUM5.5

Уязвимость компонентов mm/page_table_check ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03404
MEDIUM6.1

Уязвимость компонента xhci ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-03-27Modified: 2025-08-19
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:C
References
BDU:2025-03406
MEDIUM5.5

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-03407
MEDIUM5.5

Уязвимость функции ext4_xattr_block_cache_find() компонента ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03409
MEDIUM5.5

Уязвимость функции fib6_nh_init() компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03411
MEDIUM5.5

Уязвимость функции imx_uart_console_write() компонента serial ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03412
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03416
MEDIUM5.5

Уязвимость компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03417
MEDIUM5.5

Уязвимость компонента ipv6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2026-03-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03423
MEDIUM5.5

Уязвимость компонентов drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03424
MEDIUM5.5

Уязвимость компонентов drivers/perf ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03425
MEDIUM5.5

Уязвимость компонента bonding ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03426
MEDIUM5.5

Уязвимость компонентов RDMA/hns ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03427
MEDIUM5.5

Уязвимость функции vidi_get_modes() компонентов drm/exynos/vidi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03428
MEDIUM5.5

Уязвимость функции logi_dj_recv_switch_to_dj_mode() компонента HID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03429
MEDIUM6.1

Уязвимость функции mesh_path_discard_frame() компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:P
References
BDU:2025-03430
MEDIUM5.5

Уязвимость функции __ocfs2_change_file_space() компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03432
MEDIUM4.4

Уязвимость функции smack_post_notification() компонента ima ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-03433
MEDIUM5.5

Уязвимость функции xfrm6_get_saddr() компонента xfrm6 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03434
MEDIUM5.5

Уязвимость функции io_ring_buffer_select() компонента io_uring ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-08-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03435
MEDIUM5.5

Уязвимость функции nilfs_empty_dir() компонента nilfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03436
MEDIUM5.5

Уязвимость компонента fpga ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03437
MEDIUM5.5

Уязвимость компонента smb ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03439
MEDIUM4.4

Уязвимость функции bcm6358_quirks() компонента mips ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-03440
MEDIUM5.5

Уязвимость компонентов drm/shmem-helper ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03442
MEDIUM4.4

Уязвимость компонента ice ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2026-01-20
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-03445
MEDIUM5.5

Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03446
MEDIUM5.5

Уязвимость компонента ACPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03447
MEDIUM5.5

Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03448
MEDIUM5.5

Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03452
MEDIUM5.5

Уязвимость функции sanity_check_inode() компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03488
MEDIUM5.5

Уязвимость компонента ceph ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-27Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03535
MEDIUM5.5

Уязвимость функции amdgpu_job_prepare_job() драйвера (drivers/gpu/drm/amd/amdgpu/amdgpu_job.c) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-31Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03537
MEDIUM5.5

Уязвимость функции ps_cancel_timer() драйвера Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-03-31Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03585
MEDIUM5.5

Уязвимость функции mana_destroy_txq() драйвера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-01Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03586
MEDIUM5.5

Уязвимость функции construct_phy() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-01Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03587
MEDIUM6.5

Уязвимость функции acpi_has_cpu_in_madt() модуля arch/loongarch/include/asm/acpi.h поддержки архитектуры LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-06-09
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03606
MEDIUM5.5

Уязвимость функции ff_layout_cancel_io() модуля fs/nfs/flexfilelayout/flexfilelayout.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03608
MEDIUM5.5

Уязвимость функции ice_bridge_setlink() модуля drivers/net/ethernet/intel/ice/ice_main.c - драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03609
MEDIUM5.5

Уязвимость функции thunderstrike_led_create() модуля drivers/hid/hid-nvidia-shield.c - драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03612
MEDIUM5.5

Уязвимость функции nouveau_fence_context_kill() модуля drivers/gpu/drm/nouveau/nouveau_fence.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Nouveau (NVIDIA) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03613
MEDIUM6.0

Уязвимость функции acpi_processor_power_exit() модуля drivers/acpi/processor_idle.c - драйвера поддержки ACPI (расширенный интерфейс конфигурации и питания) ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-08-19
CVSS 3.xMEDIUM 6.0
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-03614
MEDIUM6.3

Уязвимость функции path_init() модуля drivers/interconnect/core.c - драйвера поддержки межсоединений ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-06-09
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:N/A:C
References
BDU:2025-03615
MEDIUM6.4

Уязвимость функции pvr2_context_exit() модуля drivers/media/usb/pvrusb2/pvrusb2-context.c - драйвера поддержки мультимедийных устройств USB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-04-01Modified: 2025-06-09
CVSS 3.xMEDIUM 6.4
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2025-03616
MEDIUM5.5

Уязвимость функции amdgpu_dm_atomic_check() модуля drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03617
MEDIUM5.5

Уязвимость функции unix_gc() модуля net/unix/garbage.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03618
MEDIUM5.5

Уязвимость функции nilfs_segctor_prepare_write() модуля fs/nilfs2/segment.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-01Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03686
MEDIUM5.5

Уязвимость функции dm_update_mst_vcpi_slots_for_dsc() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-02Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03689
MEDIUM5.5

Уязвимость функции nvmet_tcp_install_queue() модуля drivers/nvme/target/tcp.c драйвера ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-02Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03690
MEDIUM5.5

Уязвимость функции configure_lttpr_mode_non_transparent() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-02Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03691
MEDIUM5.5

Уязвимость функции dcn_bw_update_from_pplib_fclks() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-02Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03692
MEDIUM5.5

Уязвимость функции amdgpu_device_gpu_recover() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-02Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03699
MEDIUM5.5

Уязвимость функции mlx5e_handle_rx_cqe_mpwrq_shampo() драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-02Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03700
MEDIUM5.5

Уязвимость функции irqfd_wakeup() драйверов Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-02Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03751
MEDIUM5.5

Уязвимость функции mptcp_pm_nl_rm_addr_or_subflow() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-03Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03756
MEDIUM5.5

Уязвимость функции dpu_encoder_virt_atomic_mode_set() драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-03Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03760
MEDIUM5.5

Уязвимость функции bond_ipsec_add_sa() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-03Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03905
MEDIUM5.5

Уязвимость компонента spectrum_acl_tcam.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03906
MEDIUM5.5

Уязвимость компонента nft_chain_filter.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03909
MEDIUM5.5

Уязвимость компонента iommu/vt-d ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03911
MEDIUM4.7

Уязвимость компонента fs/quota/dquot.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-03912
LOW3.3

Уязвимость компонента crypto/xilinx/zynqmp-aes-gcm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2026-01-20
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-03913
MEDIUM5.5

Уязвимость компонента i40e_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03914
MEDIUM5.5

Уязвимость компонента pgtable.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03915
MEDIUM5.5

Уязвимость компонента iso.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03916
MEDIUM6.1

Уязвимость компонента dma-mapping ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2026-01-20
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:C
References
BDU:2025-03919
HIGH7.0

Уязвимость функций reserve_compress_blocks/release_compress_blocks компонента fs/f2fs/file.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2025-06-09
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2025-03921
MEDIUM4.4

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных

Published: 2025-04-09Modified: 2025-06-09
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:C/A:N
References
BDU:2025-03922
MEDIUM5.5

Уязвимость компонента ipvlan ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03927
MEDIUM4.4

Уязвимость компонента x86/mm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2026-01-20
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-03928
MEDIUM5.5

Уязвимость компонента drm/mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03929
MEDIUM5.5

Уязвимость компонента mm/usercopy.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03930
MEDIUM5.5

Уязвимость компонента net/core/dev.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным

Published: 2025-04-09Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2025-03931
MEDIUM5.5

Уязвимость компонента wireguard/receive.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-03932
MEDIUM5.5

Уязвимость компонента events_base.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-09Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04157
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с недостатками в обработке исключительных состояний, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04158
MEDIUM5.5

Уязвимость функции mlx5e_tir_builder_alloc() компонента net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04159
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с ошибками управления состоянием, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04160
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04162
MEDIUM5.5

Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04163
MEDIUM5.5

Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю оказать влияние на доступность защищаемой информации

Published: 2025-04-10Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04173
MEDIUM6.5

Уязвимость компонента tun.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-08-19
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04175
MEDIUM5.5

Уязвимость компонента landlock ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04181
MEDIUM6.3

Уязвимость компонента enic_main.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, нарушить их целостность, а также вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:P/A:C
References
BDU:2025-04182
MEDIUM5.5

Уязвимость компонента light.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04183
LOW3.3

Уязвимость компонента data.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-04184
MEDIUM5.5

Уязвимость компонента cadence_master.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04185
MEDIUM5.5

Уязвимость компонента max3100.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04186
MEDIUM5.5

Уязвимость компонента fslog.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04187
MEDIUM5.5

Уязвимость компонента stk1160-video.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04188
LOW3.3

Уязвимость компонента sound/pci/hda/hda_cs_dsp_ctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-06-09
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-04189
MEDIUM5.5

Уязвимость компонента tcp_dctcp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-08-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04193
HIGH7.1

Уязвимость компонента tap.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-10Modified: 2025-08-19
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2025-04258
MEDIUM5.5

Уязвимость функции geneve_rx() модуля drivers/net/geneve.c - драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-11Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04260
MEDIUM5.5

Уязвимость функции hsr_get_node() модуля net/hsr/hsr_framereg.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-04-11Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04349
MEDIUM5.5

Уязвимость функции lgdt3306a_probe() модуля drivers/media/dvb-frontends/lgdt3306a.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04380
HIGH7.8

Уязвимость функции iwl_mvm_mld_rm_sta() модуля drivers/net/wireless/intel/iwlwifi/mvm/mld-sta.c - драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-04-14Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-04395
MEDIUM5.5

Уязвимость функции aoeblk_gdalloc() модуля drivers/block/aoe/aoeblk.c - драйвера поддержки блочных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04396
MEDIUM5.5

Уязвимость функции get_firmware_info_v3_2() модуля drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04401
MEDIUM6.3

Уязвимость функции __dm_internal_suspend() модуля drivers/md/dm.c - драйвера поддержки нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-04-14Modified: 2025-08-19
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
CVSS 2.0MEDIUM 6.5
CVSS:2.0/AV:N/AC:L/Au:S/C:P/I:P/A:P
References
BDU:2025-04402
MEDIUM6.3

Уязвимость определения структуры f2fs_fault_info{} модуля fs/f2fs/f2fs.h поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-06-09
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:N/A:C
References
BDU:2025-04404
MEDIUM6.5

Уязвимость функции bt_sock_recvmsg() модуля net/bluetooth/af_bluetooth.c подсистемы Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-06-09
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 6.1
CVSS:2.0/AV:A/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2025-04405
MEDIUM6.7

Уязвимость функции parse_server_interfaces() модуля fs/smb/client/smb2ops.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-10-23
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:A/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H
CVSS 2.0HIGH 7.1
CVSS:2.0/AV:A/AC:L/Au:S/C:N/I:C/A:C
References
BDU:2025-04408
MEDIUM5.5

Уязвимость функции kvm_hyp_reserve() модуля arch/arm64/kvm/pkvm.c подсистемы виртуализации на платформе ARM 64-бит ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04475
MEDIUM6.2

Уязвимость функции dce110_disable_stream() модуля drivers/gpu/drm/amd/display/dc/dce110/dce110_hw_sequencer.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-10-24
CVSS 3.xMEDIUM 6.2
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2025-04511
MEDIUM5.5

Уязвимость компонента uprobes ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04513
MEDIUM5.5

Уязвимость компонента r8169 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04527
MEDIUM6.7

Уязвимость функции xsk_setsockopt() модуля net/xdp/xsk.c реализации сетевых функций ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и целостность защищаемой информации

Published: 2025-04-14Modified: 2025-06-09
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
CVSS 2.0MEDIUM 5.6
CVSS:2.0/AV:L/AC:H/Au:N/C:C/I:C/A:N
References
BDU:2025-04529
MEDIUM6.2

Уязвимость функции hv_uio_cleanup() модуля drivers/uio/uio_hv_generic.c - драйвера поддержки пользовательского ввода-вывода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-14Modified: 2025-10-24
CVSS 3.xMEDIUM 6.2
CVSS:3.x/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.9
CVSS:2.0/AV:L/AC:L/Au:N/C:N/I:N/A:C
References
BDU:2025-04547
HIGH7.8

Уязвимость функции smu_v13_0_update_pcie_parameters() модуля drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-04-15Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-04549
HIGH7.8

Уязвимость функции dfx_regs_uninit() драйвера drivers/crypto/hisilicon/debugfs.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-04-15Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-04550
HIGH7.8

Уязвимость функции ath11k_dp_process_rx() модуля drivers/net/wireless/ath/ath11k/dp_rx.c - драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-04-15Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-04552
HIGH7.8

Уязвимость функции cm3_helper_translate_curve_to_hw_format() компонента AMD Display драйвера /drivers/gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-04-15Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-04553
HIGH7.8

Уязвимость функции cifs_strndup_from_utf16() модуля /fs/smb/client/reparse.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-04-15Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-04631
MEDIUM5.5

Уязвимость функции ipheth_rcvbulk_callback() драйвера поддержки сетевых адаптеров USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-16Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04633
MEDIUM5.5

Уязвимость функции hda_sdw_machine_select() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04639
MEDIUM5.5

Уязвимость функции stm32_cryp_irq_thread() - драйвера криптографического ускорителя ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-16Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04641
MEDIUM5.5

Уязвимость функции hisi_spi_probe() драйвера устройств SPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-16Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04658
MEDIUM5.5

Уязвимость функции iio_read_channel_info() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-16Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04689
HIGH7.8

Уязвимость функции __do_sys_remap_file_pages() модуля mm/mmap.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-04-17Modified: 2026-01-20
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-04700
MEDIUM5.5

Уязвимость функции battery_hook_unregister() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-18Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04701
MEDIUM5.5

Уязвимость функции ocfs2_reflink_xattr_inline() кластерной файловой системы ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-18Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04702
MEDIUM4.7

Уязвимость функции ppp_channel_bridge_input() компонента ppp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-18Modified: 2026-01-20
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-04703
MEDIUM5.5

Уязвимость функции qdisc_pkt_len_init() модуля net/core/dev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-18Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04704
MEDIUM5.5

Уязвимость функции exit_round_robin() компонента ACPI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-18Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04705
MEDIUM5.5

Уязвимость функции __skb_set_length() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-04-18Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-04990
HIGH7.8

Уязвимость функции ocfs2_global_read_info() модуля /fs/ocfs2/quota_local.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-04-28Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-05118
MEDIUM5.5

Уязвимость компонента ACPICA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05126
MEDIUM5.5

Уязвимость компонента mailbox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05127
MEDIUM5.5

Уязвимость компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05135
MEDIUM4.7

Уязвимость функции spin_lock() компонента vfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2025-10-29
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05136
MEDIUM5.5

Уязвимость функции __jbd2_log_wait_for_space() модуля fs/jbd2/checkpoint.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05137
MEDIUM5.5

Уязвимость функции ocfs2_journal_shutdown() компонента ocfs2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05138
MEDIUM5.5

Уязвимость функции qdisc_pkt_len_init() компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05139
MEDIUM5.5

Уязвимость функции ioc_forgive_debts() компонента blk_iocost ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-02Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05183
MEDIUM5.5

Уязвимость функции static_call_module_notify() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-05Modified: 2025-07-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05184
MEDIUM5.5

Уязвимость функции sctp_listen_start() компонента sctp ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-05Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05185
MEDIUM5.5

Уязвимость функций nf_dup_ipv4() и nf_dup_ipv6() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-05Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05879
MEDIUM5.5

Уязвимость функции adl_get_hybrid_cpu_type() модуля arch/x86/events/intel/core.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2025-07-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05913
MEDIUM5.5

Уязвимость функции btnxpuart_close() драйвера поддержки устройств Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05914
MEDIUM5.5

Уязвимость функции create_lease_buf() подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05915
MEDIUM5.5

Уязвимость функции ice_vsi_free() драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2025-06-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05916
MEDIUM5.5

Уязвимость функции irqfd_shutdown() поддержки драйверов Xen ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05917
MEDIUM5.5

Уязвимость функции rtw_usb_init_rx() драйвера поддержки адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05921
MEDIUM5.5

Уязвимость функции ice_prepare_for_reset() драйвера поддержки сетевых адаптеров Ethernet Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2025-07-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05928
MEDIUM5.5

Уязвимость функции debug_event_write_work_handler() модуля drivers/gpu/drm/amd/amdkfd/kfd_debug.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.

Published: 2025-05-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05930
MEDIUM5.5

Уязвимость функции resource_build_bit_depth_reduction_params() драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05935
MEDIUM5.5

Уязвимость функции ufshcd_remove() драйвера UFS (Universal Flash Storage) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-23Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05976
MEDIUM5.5

Уязвимость функции gfx_v11_0_hw_init() драйвера поддержки инфраструктуры прямого рендеринга (DRI) AMD GPU ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-26Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-05977
MEDIUM5.5

Уязвимость функции ath12k_station_assoc() драйвера поддержки адаптеров беспроводной связи Atheros/Qualcomm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-26Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06023
MEDIUM5.5

Уязвимость модуля drivers/gpu/drm/vmwgfx/vmwgfx_kms.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-05-27Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06318
HIGH7.8

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-03Modified: 2026-02-17
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06335
MEDIUM5.5

Уязвимость функции __thermal_cooling_device_register() и thermal_cooling_device_destroy_sysfs() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06397
MEDIUM5.5

Уязвимость функции check_session_id(), smb2_check_user_session(), smb2_sess_setup(), smb2_session_logoff(), smb3_decrypt_req(), ksmbd_session_lookup(), ksmbd_session_lookup_slowpath() и ksmbd_get_encryption_key() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-05Modified: 2026-01-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06407
MEDIUM5.5

Уязвимость компонента Bluetooth ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-05Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06409
MEDIUM5.5

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-05Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-06971
MEDIUM4.6

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-19Modified: 2025-10-24
CVSS 3.xMEDIUM 4.6
CVSS:3.x/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
CVSS 2.0MEDIUM 4.0
CVSS:2.0/AV:A/AC:H/Au:S/C:P/I:P/A:P
References
BDU:2025-06991
HIGH8.1

Уязвимость функции __vmbus_establish_gpadl() модуля drivers/hv/channel.c - драйвера поддержки гостевого режима Microsoft Hyper-V ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-19Modified: 2025-10-24
CVSS 3.xHIGH 8.1
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.6
CVSS:2.0/AV:N/AC:H/Au:N/C:C/I:C/A:C
References
BDU:2025-06992
HIGH7.8

Уязвимость функции xbc_init() модуля include/linux/bootconfig.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-19Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-06994
HIGH7.8

Уязвимость функции ath12k_dp_rx_process() компонента wifi драйвера /drivers/net/wireless/ath/ath12k/dp_rx.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность.

Published: 2025-06-19Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-06995
HIGH7.8

Уязвимость функции amdkfd_free_gtt_mem() драйвера /drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-06-19Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-06998
HIGH7.8

Уязвимость функции HPIMSGX__init() в модуле sound/pci/asihpi/hpimsgx.c компонента asihpi модуля /sound/pci/asihpi/hpimsgx.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-19Modified: 2025-10-29
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-06999
HIGH7.5

Уязвимость функции skb_put_padto() компонента Ethernet Frame Handler драйвера /drivers/net/ethernet/lantiq_etop.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-19Modified: 2025-10-29
CVSS 3.xHIGH 7.5
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0HIGH 7.8
CVSS:2.0/AV:N/AC:L/Au:N/C:C/I:N/A:N
References
BDU:2025-07000
HIGH7.1

Уязвимость функции check_func_arg() модуля kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-19Modified: 2025-10-24
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:C/A:C
References
BDU:2025-07001
HIGH7.8

Уязвимость функции ModeSupportAndSystemConfiguration() драйвера drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность и доступность защищаемой информации

Published: 2025-06-19Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-07002
HIGH7.8

Уязвимость функции kvm_arch_vcpu_ioctl() модуля arch/x86/kvm/x86.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации.

Published: 2025-06-19Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-07455
HIGH8.1

Уязвимость функции vmbus_connect() модуля drivers/hv/connection.c - драйвера поддержки гостевого режима Microsoft Hyper-V ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-25Modified: 2026-02-16
CVSS 3.xHIGH 8.1
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.6
CVSS:2.0/AV:N/AC:H/Au:N/C:C/I:C/A:C
References
BDU:2025-07473
HIGH7.8

Уязвимость функции reiserfs_rename() модуля fs/reiserfs/namei.c поддержки файловой системы ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-25Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-07479
HIGH7.8

Уязвимость функции j1939_sk_match_dst() модуля net/can/j1939/socket.c поддержки сокетов j1939 шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-25Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-07482
HIGH7.8

Уязвимость функции find_or_create_cached_dir() модуля fs/smb/client/cached_dir.c поддержки клиента SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-25Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-07485
HIGH7.8

Уязвимость функции tcf_mirred_to_dev() модуля net/sched/act_mirred.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-25Modified: 2026-02-16
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-07500
HIGH7.1

Уязвимость функции iocg_pay_debt() модуля block/blk-iocost.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-06-25Modified: 2026-02-16
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-07529
HIGH8.0

Уязвимость компонента microchip-core ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-25Modified: 2025-10-24
CVSS 3.xHIGH 8.0
CVSS:3.x/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0HIGH 7.7
CVSS:2.0/AV:A/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-07592
MEDIUM5.5

Уязвимость модуля arch/x86/kernel/apic/io_apic.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-06-26Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07831
MEDIUM5.5

Уязвимость компонента tracing/trigger ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-03Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07976
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с чрезмерным итерированием, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07978
MEDIUM5.5

Уязвимость функции exfat_load_bitmap() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07979
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с ошибками при обновлении счетчика ссылок, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07982
MEDIUM5.5

Уязвимость функции mwifiex_cmd_802_11_scan_ext() компонента drivers/net/wireless/marvell/mwifiex/scan.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07983
MEDIUM4.7

Уязвимость функции ext4_ind_migrate() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-29
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-07984
MEDIUM5.5

Уязвимость компонента drm/amd/display ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07985
MEDIUM5.5

Уязвимость компонента net/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07986
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования нулевого указателя NULL, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07987
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с недостаточной блокировкой, позволяющая нарушителю вызвать отказ в обслуживании(DoS)

Published: 2025-07-04Modified: 2025-10-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07989
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования указателя NULL, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07992
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с неправильным контролем над ресурсом на протяжении его жизненного цикла, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07993
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с ошибками разыменования нулевого указателя, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07994
MEDIUM5.5

Уязвимость функций iwl_mvm_tx_skb_sta(), iwl_mvm_tx_mpdu() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-07995
MEDIUM5.5

Уязвимость ядра операционной системы Linux, связанная с использованием памяти после её освобождения, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08000
MEDIUM4.7

Уязвимость компонента fs/f2fs/file.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-08019
LOW3.3

Уязвимость компонента net/mac80211 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-08022
MEDIUM5.5

Уязвимость компонента net/mlx5e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08023
LOW3.3

Уязвимость компонента altera-msgdma ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-08027
MEDIUM4.7

Уязвимость компонента drivers/net/ethernet/mellanox/mlx5 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-08029
MEDIUM5.5

Уязвимость компонента s390/uv ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08031
MEDIUM5.5

Уязвимость компонента ipvs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08032
MEDIUM5.5

Уязвимость компонента flow_dissector ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08036
MEDIUM5.5

Уязвимость компонента ntb_netdev.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08038
MEDIUM5.5

Уязвимость компонентов core.c, fabrics-cmd-auth.c, fabrics-cmd.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08039
MEDIUM5.5

Уязвимость компонента ondemand.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08040
MEDIUM5.5

Уязвимость компонента ondemand.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08041
HIGH7.8

Уязвимость компонента soc-topology.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-08044
MEDIUM4.3

Уязвимость компонента smb2pdu.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-04Modified: 2026-03-19
CVSS 3.xMEDIUM 4.3
CVSS:3.x/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0MEDIUM 4.0
CVSS:2.0/AV:N/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-08056
HIGH7.8

Уязвимость компонентов vgic-init.c, vgic-mmio-v3.c, vgic.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-08058
MEDIUM4.7

Уязвимость компонентов tty_ldisc.c, vt.c, tty_driver.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-08059
MEDIUM4.1

Уязвимость компонента pageattr.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-08062
MEDIUM5.5

Уязвимость компонентов cmd.c, driver.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08063
MEDIUM4.4

Уязвимость компонента qplib_fp.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-08066
MEDIUM6.6

Уязвимость компонентов mpi3mr_app.c, scsi_bsg_mpi3mr.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2026-03-19
CVSS 3.xMEDIUM 6.6
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
CVSS 2.0MEDIUM 5.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:P/A:C
References
BDU:2025-08067
MEDIUM5.5

Уязвимость компонентов bloom_filter.c, bloom_filter_map.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2026-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08068
MEDIUM5.5

Уязвимость компонента ioctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2026-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08069
MEDIUM6.1

Уязвимость компонента llcp_sock.c ядра операционной системы Linux, позволяющая нарушителю а также вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-12-08
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:C
References
BDU:2025-08071
MEDIUM5.5

Уязвимость компонента amdgpu_dm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2026-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08072
MEDIUM5.5

Уязвимость компонента channel.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным

Published: 2025-07-07Modified: 2026-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:N
References
BDU:2025-08073
MEDIUM4.4

Уязвимость компонентов hclge_main.c, hclgevf_main.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2026-03-19
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-08074
MEDIUM6.1

Уязвимость компонента gpiolib-cdev.c ядра операционной системы Linux, позволяющая нарушителю а также вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2026-03-19
CVSS 3.xMEDIUM 6.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L
CVSS 2.0MEDIUM 5.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:P
References
BDU:2025-08075
LOW3.8

Уязвимость компонентов sch_taprio.c, taprio.json ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xLOW 3.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:P
References
BDU:2025-08076
MEDIUM5.5

Уязвимость компонента af_ax25.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08077
MEDIUM5.5

Уязвимость компонента hugetlb.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08082
MEDIUM5.5

Уязвимость компонента l2cap_sock.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08083
MEDIUM5.5

Уязвимость компонентов inode.c, ioctl.c, root-tree.c, root-tree.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08085
MEDIUM5.5

Уязвимость компонента omap_prm.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-07Modified: 2025-10-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-08086
LOW3.3

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным

Published: 2025-07-07Modified: 2026-01-20
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2025-08539
MEDIUM4.4

Уязвимость ядра операционной системы Linux, связанная с ошибками при освобождении ресурсов, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-07-16Modified: 2025-10-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-10240
HIGH7.1

Уязвимость ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность и доступность защищаемой информации

Published: 2025-08-25Modified: 2026-01-20
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-10570
MEDIUM5.5

Уязвимость функции mtk_drm_gem_dumb_create() модуля drivers/gpu/drm/mediatek/mtk_drm_gem.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт Mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-09-01Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-11885
HIGH7.1

Уязвимость компонента fs/squashfs ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании

Published: 2025-09-28Modified: 2025-10-29
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-11956
MEDIUM5.5

Уязвимость компонента mediatek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-09-28Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-11958
MEDIUM6.5

Уязвимость компонента netfilter ядра операционной системы Linux, позволяющая нарушителю нарушить целостность данных, а также вызвать отказ в обслуживании

Published: 2025-09-28Modified: 2025-10-29
CVSS 3.xMEDIUM 6.5
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H
CVSS 2.0MEDIUM 6.1
CVSS:2.0/AV:N/AC:H/Au:N/C:N/I:P/A:C
References
BDU:2025-11996
MEDIUM4.7

Уязвимость компонентов ipv4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-09-28Modified: 2026-02-16
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-12050
MEDIUM4.4

Уязвимость компонента drivers/media/i2c/et8ek8/et8ek8 ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальным данным, а также вызвать отказ в обслуживании

Published: 2025-09-28Modified: 2026-02-16
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L
CVSS 2.0LOW 3.2
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:P
References
BDU:2025-12228
MEDIUM5.5

Уязвимость компонента displayport.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-09-28Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-12231
MEDIUM5.5

Уязвимость компонента vcodec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-09-28Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-12232
MEDIUM5.5

Уязвимость компонента vcodec ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-09-28Modified: 2026-02-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-12481
LOW3.3

Уязвимость компонента switchdev ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность данных

Published: 2025-10-06Modified: 2026-01-20
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:P/A:N
References
BDU:2025-12899
HIGH7.0

Уязвимость функции ufshcd_queuecommand() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-14Modified: 2026-02-17
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2025-12936
HIGH8.8

Уязвимость компонента VMM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-15Modified: 2025-11-26
CVSS 3.xHIGH 8.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-12978
MEDIUM5.5

Уязвимость функции f2fs_remount() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-15
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-12996
MEDIUM5.9

Уязвимость функции recv() компонента tls ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-16Modified: 2026-01-20
CVSS 3.xMEDIUM 5.9
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 5.4
CVSS:2.0/AV:N/AC:H/Au:N/C:N/I:N/A:C
References
BDU:2025-13304
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13305
MEDIUM4.7

Уязвимость компонента KVM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-13306
MEDIUM5.5

Уязвимость компонента parisc ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13309
MEDIUM5.5

Уязвимость компонента sc8180x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-23Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13310
MEDIUM5.5

Уязвимость компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13311
MEDIUM4.7

Уязвимость компонентов mm/swap ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-13312
MEDIUM5.5

Уязвимость компонента LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13313
MEDIUM6.3

Уязвимость компонента i40e ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-23
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-13346
MEDIUM5.5

Уязвимость компонента wifi ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13347
MEDIUM5.5

Уязвимость компонента igc ядра операционной системы Linux, позволяющая нарушителю повысить привилегии в системе

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13348
MEDIUM5.5

Уязвимость компонента media ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13349
MEDIUM5.5

Уязвимость компонентов x86/efistub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13350
MEDIUM5.5

Уязвимость компонента LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13353
HIGH7.8

Уязвимость компонентов drm/vc4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2025-13354
MEDIUM5.5

Уязвимость компонентов x86/coco ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13355
MEDIUM5.5

Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13356
MEDIUM5.5

Уязвимость компонентов drm/i915/bios ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13357
MEDIUM5.5

Уязвимость компонента dma-direct ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13358
MEDIUM5.5

Уязвимость компонента net ядра операционной системы Linux, позволяющая нарушителю получить доступ к конфиденциальной информации

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13359
MEDIUM5.5

Уязвимость компонента block ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13360
MEDIUM5.5

Уязвимость компонента f2fs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13364
MEDIUM5.5

Уязвимость компонентов drm/amd/pm ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13365
MEDIUM5.5

Уязвимость компонента hns3 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-10-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13767
MEDIUM5.5

Уязвимость функции vdec_h264_slice_decode() модуля drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_h264_req_if.c драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая удаленному нарушителю вызвать отказ в обслуживании

Published: 2025-11-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-13862
MEDIUM5.5

Уязвимость функции adreno_gpu_init() модуля drivers/gpu/drm/msm/adreno/adreno_gpu.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-14134
MEDIUM5.3

Уязвимость функции of_modalias() модуля drivers/of/module.c - драйвера поддержки дерева устройств и открытой прошивки ядра операционной системы Linux, позволяющая удаленному нарушителю вызвать отказ в обслуживании

Published: 2025-11-14
CVSS 3.xMEDIUM 5.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
CVSS 2.0MEDIUM 5.0
CVSS:2.0/AV:N/AC:L/Au:N/C:N/I:N/A:P
References
BDU:2025-14284
MEDIUM5.5

Уязвимость функции insert_header() модуля fs/proc/proc_sysctl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-14286
MEDIUM5.5

Уязвимость функции mpi_ec_init() модуля lib/mpi/ec.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-14290
MEDIUM5.5

Уязвимость функции j1939_netdev_start() модуля net/can/j1939/main.c поддержки сокетов j1939 шины CAN ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-14292
MEDIUM5.5

Уязвимость функции gss_import_v2_context() модуля net/sunrpc/auth_gss/gss_krb5_mech.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-16Modified: 2026-02-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-14293
MEDIUM5.5

Уязвимость функции esw_inline_mode_to_devlink() модуля drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c драйвера поддержки сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-14295
HIGH7.1

Уязвимость функции create_core_data() модуля drivers/hwmon/coretemp.c ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-11-16
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-14298
MEDIUM5.5

Уязвимость функции optc32_disable_crtc() модуля drivers/gpu/drm/amd/display/dc/dcn32/dcn32_optc.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-14300
MEDIUM5.5

Уязвимость функции check_ptr_to_map_access() модуля kernel/bpf/verifier.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-14593
MEDIUM4.4

Уязвимость функции grandparent() модуля drivers/cxl/core/port.c драйвера поддержки устройств CXL (Compute Express Link) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-11-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-15041
MEDIUM5.5

Уязвимость функции dcn21_set_backlight_level() модуля drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-15043
MEDIUM4.1

Уязвимость функции process_isoc_td() модуля drivers/usb/host/xhci-ring.c - драйвера поддержки устройств шины USB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-15047
MEDIUM4.7

Уязвимость функции mfill_atomic() модуля mm/userfaultfd.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-15048
HIGH7.1

Уязвимость функции tcf_block_playback_offloads() модуля net/sched/cls_api.c подсистемы управления трафиком net/sched ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации или вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xHIGH 7.1
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
CVSS 2.0MEDIUM 6.2
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:N/A:C
References
BDU:2025-15058
MEDIUM5.5

Уязвимость функции tipc_nl_bearer_add() модуля net/tipc/bearer.c реализации протокола TIPC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-15060
MEDIUM5.5

Уязвимость функции dcn21_set_abm_immediate_disable() модуля drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-15067
MEDIUM4.7

Уязвимость определения структуры debug_defaults_drv{} модуля drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-15085
MEDIUM4.1

Уязвимость функции vdec_av1_slice_free_working_buffer() модуля drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_av1_req_lat_if.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.7
CVSS:2.0/AV:L/AC:H/Au:M/C:N/I:N/A:C
References
BDU:2025-15086
MEDIUM4.4

Уязвимость функции dpu_encoder_helper_phys_cleanup() модуля drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-15231
HIGH7.3

Уязвимость функции tls_do_decryption() (net/tls/tls_sw.c) ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии

Published: 2025-12-05Modified: 2026-03-11
CVSS 3.xHIGH 7.3
CVSS:3.x/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
CVSS 2.0HIGH 7.5
CVSS:2.0/AV:N/AC:L/Au:N/C:P/I:P/A:P
References
BDU:2025-15382
MEDIUM4.0

Уязвимость функции smb2_find_context_vals модуля fs/smb/server/oplock.c подсистемы SMB ядра операционной системы Linux, позволяющая удаленному нарушителю получить доступ к защищаемой информации

Published: 2025-12-08
CVSS 3.xMEDIUM 4.0
CVSS:3.x/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N
CVSS 2.0LOW 2.6
CVSS:2.0/AV:N/AC:H/Au:N/C:P/I:N/A:N
References
BDU:2025-15385
MEDIUM5.5

Уязвимость функции __set_extent_info() модуля fs/f2fs/extent_cache.c поддержки файловой системы F2FS ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-15386
MEDIUM4.4

Уязвимость функции handle_kernel_stack_overflow() модуля arch/riscv/include/asm/asm-prototypes.h на процессорах с архитектурой RISC-V ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-08
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-15392
MEDIUM4.4

Уязвимость функции pmu_sbi_ovf_handler() модуля drivers/perf/riscv_pmu_sbi.c - драйвера поддержки мониторинга производительности ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-08
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.3
CVSS:2.0/AV:L/AC:L/Au:M/C:N/I:N/A:C
References
BDU:2025-15395
MEDIUM6.7

Уязвимость функции aspeed_video_get_resolution() модуля drivers/media/platform/aspeed/aspeed-video.c - драйвера поддержки мультимедийных устройств ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2025-12-08
CVSS 3.xMEDIUM 6.7
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.5
CVSS:2.0/AV:L/AC:L/Au:M/C:C/I:C/A:C
References
BDU:2025-16135
MEDIUM5.5

Уязвимость функции ksmbd_conn_free() модуля fs/smb/server/connection.c подсистемы SMB ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-16228
MEDIUM5.5

Уязвимость функции __extent_writepage() компонента btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-16230
MEDIUM4.1

Уязвимость функции gs_usb_disconnect() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-24Modified: 2026-02-17
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-16235
MEDIUM4.4

Уязвимость функции rtw88_usb() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-24Modified: 2026-02-17
CVSS 3.xMEDIUM 4.4
CVSS:3.x/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2025-16262
MEDIUM4.1

Уязвимость функции __stack_chk_fail() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2025-12-24Modified: 2026-02-17
CVSS 3.xMEDIUM 4.1
CVSS:3.x/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2025-16315
LOW3.3

Уязвимость функции run_unpack() компонента ntfs3 ядра операционной системы Linux, позволяющая нарушителю получить доступ к защищаемой информации

Published: 2025-12-24
CVSS 3.xLOW 3.3
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CVSS 2.0LOW 1.7
CVSS:2.0/AV:L/AC:L/Au:S/C:P/I:N/A:N
References
BDU:2026-01327
MEDIUM6.3

Уязвимость функции flush_cache_all_local() модуля arch/parisc/include/asm/cacheflush.h поддержки архитектуры PA-RISC ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на целостность защищаемой информации или вызвать отказ в обслуживании

Published: 2026-02-06
CVSS 3.xMEDIUM 6.3
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS 2.0MEDIUM 5.5
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:C/A:C
References
BDU:2026-01440
MEDIUM5.5

Уязвимость команды WMI_TXSTATUS_EVENTID ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-01446
MEDIUM5.5

Уязвимость функции __ext4_fill_super() модуля fs/ext4/super.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-01448
MEDIUM5.5

Уязвимость функции iwl_txq_reclaim() модуля drivers/net/wireless/intel/iwlwifi/queue/tx.c драйвера поддержки адаптеров беспроводной связи Intel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-01449
MEDIUM5.5

Уязвимость функции free_netvsc_device() модуля drivers/net/hyperv/netvsc.c драйвера поддержки сетевых устройств ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-01450
MEDIUM5.5

Уязвимость определения структуры imx8mp_blk_ctrl_domain_data{} модуля drivers/pmdomain/imx/imx8mp-blk-ctrl.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-01451
MEDIUM5.5

Уязвимость функции ucsi_read_message_in() модуля drivers/usb/typec/ucsi/ucsi.c драйвера поддержки интерфейса системного программного обеспечения разъема USB Type- C (UCSI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-01452
MEDIUM5.5

Уязвимость функции show_ipi_list() модуля arch/loongarch/kernel/smp.c поддержки архитектуры LoongArch ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-01455
MEDIUM5.5

Уязвимость функции nilfs_prepare_segment_for_recovery() модуля fs/nilfs2/recovery.c поддержки файловой системы NILFS2 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-02-09
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-02205
HIGH7.8

Уязвимость функции load_firmware_cb() драйвера тюнеров XCeive xc2028/xc3028 ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2026-02-25Modified: 2026-03-04
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2026-02262
HIGH7.8

Уязвимость функции ufshcd_cmd_inflight() модуля drivers/ufs/core/ufshcd.c поддержки хост-контроллеров UFS (Universal Flash Storage). ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2026-02-26
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2026-03248
MEDIUM5.5

Уязвимость функции an30259a_probe() модуля drivers/leds/leds-an30259a.c ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03278
MEDIUM5.5

Уязвимость функции mlx5e_rq_to_ready() модуля drivers/net/ethernet/mellanox/mlx5/core/en_main.c драйвера сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03318
MEDIUM4.7

Уязвимость функции create_io_worker() модуля io_uring/io-wq.c интерфейса асинхронного ввода/вывода ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-18
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2026-03498
MEDIUM5.5

Уязвимость функции __sync_icache_dcache() модуля arch/arm/mm/flush.c поддержки платформы ARM ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03500
MEDIUM5.5

Уязвимость функции sof_ipc4_trigger_pipelines() модуля sound/soc/sof/ipc4-pcm.c поддержки звука SoC ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03501
MEDIUM5.5

Уязвимость функции skb_frag_ref() модуля include/linux/skbuff.h ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03508
MEDIUM5.5

Уязвимость функции panfrost_mmu_map_fault_addr() модуля drivers/gpu/drm/panfrost/panfrost_mmu.c драйвера поддержки инфраструктуры прямого рендеринга (DRI) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03509
MEDIUM5.5

Уязвимость функции mlx5_init_one_devl_locked() модуля drivers/net/ethernet/mellanox/mlx5/core/main.c драйвера поддержки сетевых адаптеров Ethernet Mellanox ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03536
MEDIUM4.7

Уязвимость функции dw_edma_v0_core_write_chunk() модуля drivers/dma/dw-edma/dw-edma-v0-core.c драйвера поддержки движка DMA ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-24
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
BDU:2026-03638
MEDIUM5.5

Уязвимость функции bpf_prog_attach_check_attach_type() модуля kernel/bpf/syscall.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03783
MEDIUM5.5

Уязвимость функции stmmac_adjust_time() модуля drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c драйвера поддержки сетевых адаптеров Ethernet STMicroelectronics ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-03943
MEDIUM5.5

Уязвимость функции ipu_bridge_connect_sensor() модуля drivers/media/pci/intel/ipu-bridge.c драйвера мультимедийных устройств на шине PCI ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-04263
MEDIUM5.5

Уязвимость функции __bio_release_pages() модуля block/bio.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-04272
MEDIUM5.5

Уязвимость функции blkcg_css_online() модуля block/blk-cgroup.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-04273
MEDIUM5.5

Уязвимость функции ks8851_rx_pkts() модуля drivers/net/ethernet/micrel/ks8851_common.c драйвера поддержки сетевых адаптеров Ethernet Micrel ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-04308
MEDIUM5.5

Уязвимость функции pstore_put_backend_records() модуля fs/pstore/inode.c поддержки постоянного хранилища ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-03-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-04385
MEDIUM5.5

Уязвимость функции bpf_link_inc() модуля kernel/bpf/syscall.c поддержки интерпретатора BPF ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-04419
HIGH7.0

Уязвимость функции rtw_core_deinit() модуля drivers/net/wireless/realtek/rtw88/main.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2026-04-01
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2026-04541
MEDIUM5.5

Уязвимость функции do_sync_mmap_readahead() модуля mm/filemap.c подсистемы управления памятью ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-05736
MEDIUM5.5

Уязвимость функции ext4_writepages() модуля fs/ext4/ext4.h файловой системы Ext4 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-05737
MEDIUM5.5

Уязвимость модуля drivers/md/raid10.c драйвера нескольких устройств (RAID и LVM) ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-05874
HIGH7.8

Уязвимость функции sendmsg() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-27
CVSS 3.xHIGH 7.8
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.8
CVSS:2.0/AV:L/AC:L/Au:S/C:C/I:C/A:C
References
BDU:2026-05887
MEDIUM5.5

Уязвимость функции acpi_get_dsd_graph() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-05902
MEDIUM5.5

Уязвимость функции blkcg_reset_stats() ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-06007
HIGH7.0

Уязвимость функции blk_mq_elv_switch_none() модуля block/blk-mq.c поддержки блочного уровня ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

Published: 2026-04-29
CVSS 3.xHIGH 7.0
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 2.0MEDIUM 6.0
CVSS:2.0/AV:L/AC:H/Au:S/C:C/I:C/A:C
References
BDU:2026-06095
MEDIUM5.5

Уязвимость функции rtw_usb_probe() в модуле drivers/net/wireless/realtek/rtw88/usb.c драйвера адаптеров беспроводной связи Realtek ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0MEDIUM 4.6
CVSS:2.0/AV:L/AC:L/Au:S/C:N/I:N/A:C
References
BDU:2026-06104
MEDIUM4.7

Уязвимость функции kgd2kfd_suspend() модуля drivers/gpu/drm/amd/amdkfd/kfd_device.c - драйвера поддержки инфраструктуры прямого рендеринга (DRI) видеокарт AMD ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

Published: 2026-04-29
CVSS 3.xMEDIUM 4.7
CVSS:3.x/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS 2.0LOW 3.8
CVSS:2.0/AV:L/AC:H/Au:S/C:N/I:N/A:C
References
CVE-2022-3533
MEDIUM5.7

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.

Published: 2022-10-17Modified: 2024-11-21
CVSS 3.xMEDIUM 5.7
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2022-3606
MEDIUM5.5

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.

Published: 2022-10-19Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2022-48669
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix potential memleak in papr_get_attr() `buf` is allocated in papr_get_attr(), and krealloc() of `buf` could fail. We need to free the original `buf` in the case of failure.

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2022-48772
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: lgdt3306a: Add a check against null-pointer-def The driver should check whether the client provides the platform_data. The following log reveals it: [ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90

Published: 2024-06-25Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2022-48872
HIGH7.0

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

Published: 2024-08-21Modified: 2024-09-06
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-0160
MEDIUM5.5

A deadlock flaw was found in the Linux kernel’s BPF subsystem. This flaw allows a local user to potentially crash the system.

Published: 2023-07-18Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-0394
MEDIUM5.5

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.

Published: 2023-01-26Modified: 2025-03-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-0615
MEDIUM5.5

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.

Published: 2023-02-06Modified: 2025-03-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-1032
MEDIUM5.5

The Linux kernel io_uring IORING_OP_SOCKET operation contained a double free in function __sys_socket_file() in file net/socket.c. This issue was introduced in da214a475f8bd1d3e9e7a19ddfeb4d1617551bab and fixed in 649c15c7691e9b13cbe9bf6c65c365350e056067.

Published: 2024-01-08Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-1079
MEDIUM6.8

A flaw was found in the Linux kernel. A use-after-free may be triggered in asus_kbd_backlight_set when plugging/disconnecting in a malicious USB device, which advertises itself as an Asus device. Similarly to the previous known CVE-2023-25012, but in asus devices, the work_struct may be scheduled by the LED controller while the device is disconnecting, triggering a use-after-free on the struct asus_kbd_leds *led structure. A malicious USB device may exploit the issue to cause memory corruption with controlled data.

Published: 2023-03-27Modified: 2025-02-19
CVSS 3.xMEDIUM 6.8
CVSS:3.x/CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-1192
MEDIUM6.5

A use-after-free flaw was found in smb2_is_status_io_timeout() in CIFS in the Linux Kernel. After CIFS transfers response data to a system call, there are still local variable points to the memory region, and if the system call frees it faster than CIFS uses it, CIFS will access a free memory region, leading to a denial of service.

Published: 2023-11-01Modified: 2024-11-21
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-1193
MEDIUM6.5

A use-after-free flaw was found in setup_async_work in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. This issue could allow an attacker to crash the system by accessing freed work.

Published: 2023-11-01Modified: 2024-11-21
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-1206
MEDIUM5.7

A hash collision flaw was found in the IPv6 connection lookup table in the Linux kernel’s IPv6 functionality when a user makes a new kind of SYN flood attack. A user located in the local network or with a high bandwidth connection can increase the CPU usage of the server that accepts IPV6 connections up to 95%.

Published: 2023-06-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.7
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-1513
LOW3.3

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.

Published: 2023-03-23Modified: 2025-02-25
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
References
CVE-2023-1855
MEDIUM6.3

A use-after-free flaw was found in xgene_hwmon_remove in drivers/hwmon/xgene-hwmon.c in the Hardware Monitoring Linux Kernel Driver (xgene-hwmon). This flaw could allow a local attacker to crash the system due to a race problem. This vulnerability could even lead to a kernel information leak problem.

Published: 2023-04-05Modified: 2025-02-12
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-1859
MEDIUM4.7

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.

Published: 2023-05-17Modified: 2025-03-18
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-1990
MEDIUM4.7

A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem.

Published: 2023-04-12Modified: 2025-03-19
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-1998
MEDIUM5.6

The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line. This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects.

Published: 2023-04-21Modified: 2025-02-13
CVSS 3.xMEDIUM 5.6
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N
References
CVE-2023-2002
MEDIUM6.8

A vulnerability was found in the HCI sockets implementation due to a missing capability check in net/bluetooth/hci_sock.c in the Linux Kernel. This flaw allows an attacker to unauthorized execution of management commands, compromising the confidentiality, integrity, and availability of Bluetooth communication.

Published: 2023-05-26Modified: 2024-11-21
CVSS 3.xMEDIUM 6.8
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:H
References
CVE-2023-2124
HIGH7.8

An out-of-bounds memory access flaw was found in the Linux kernel’s XFS file system in how a user restores an XFS image after failure (with a dirty log journal). This flaw allows a local user to crash or potentially escalate their privileges on the system.

Published: 2023-05-15Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-2162
MEDIUM5.5

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.

Published: 2023-04-19Modified: 2025-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2023-2176
HIGH7.8

A vulnerability was found in compare_netdev_and_ip in drivers/infiniband/core/cma.c in RDMA in the Linux Kernel. The improper cleanup results in out-of-boundary read, where a local user can utilize this problem to crash the system or escalation of privilege.

Published: 2023-04-20Modified: 2025-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-2194
MEDIUM6.7

An out-of-bounds write vulnerability was found in the Linux kernel's SLIMpro I2C device driver. The userspace "data->block[0]" variable was not capped to a number between 0-255 and was used as the size of a memcpy, possibly writing beyond the end of dma_buffer. This flaw could allow a local privileged user to crash the system or potentially achieve code execution.

Published: 2023-04-20Modified: 2025-04-23
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-23005
MEDIUM5.5

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.

Published: 2023-03-01Modified: 2025-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-23039
MEDIUM5.7

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().

Published: 2023-02-22Modified: 2025-03-20
CVSS 3.xMEDIUM 5.7
CVSS:3.x/CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H
References
CVE-2023-2430
MEDIUM5.5

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.

Published: 2023-07-23Modified: 2025-03-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-28328
MEDIUM5.5

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.

Published: 2023-04-19Modified: 2025-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-28866
MEDIUM5.3

In the Linux kernel through 6.2.8, net/bluetooth/hci_sync.c allows out-of-bounds access because amp_init1[] and amp_init2[] are supposed to have an intentionally invalid element, but do not.

Published: 2023-03-27Modified: 2025-05-05
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
References
CVE-2023-2985
MEDIUM5.5

A use after free flaw was found in hfsplus_put_super in fs/hfsplus/super.c in the Linux Kernel. This flaw could allow a local user to cause a denial of service problem.

Published: 2023-06-01Modified: 2025-03-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-30456
MEDIUM6.5

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.

Published: 2023-04-10Modified: 2025-03-19
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
References
CVE-2023-30772
MEDIUM6.4

The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/power/supply/da9150-charger.c if a physically proximate attacker unplugs a device.

Published: 2023-04-16Modified: 2025-05-05
CVSS 3.xMEDIUM 6.4
CVSS:3.x/CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-3161
MEDIUM5.5

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.

Published: 2023-06-12Modified: 2025-03-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3212
MEDIUM4.4

A NULL pointer dereference issue was found in the gfs2 file system in the Linux kernel. It occurs on corrupt gfs2 file systems when the evict code tries to reference the journal descriptor structure after it has been freed and set to NULL. A privileged local user could use this flaw to cause a kernel panic.

Published: 2023-06-23Modified: 2024-11-21
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3220
MEDIUM5.5

An issue was discovered in the Linux kernel through 6.1-rc8. dpu_crtc_atomic_check in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c lacks check of the return value of kzalloc() and will cause the NULL Pointer Dereference.

Published: 2023-06-20Modified: 2025-03-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3268
HIGH7.1

An out of bounds (OOB) memory access flaw was found in the Linux kernel in relay_file_read_start_pos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information.

Published: 2023-06-16Modified: 2025-03-11
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-33203
MEDIUM6.4

The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/net/ethernet/qualcomm/emac/emac.c if a physically proximate attacker unplugs an emac based device.

Published: 2023-05-18Modified: 2025-05-05
CVSS 3.xMEDIUM 6.4
CVSS:3.x/CVSS:3.1/AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-33288
MEDIUM4.7

An issue was discovered in the Linux kernel before 6.2.9. A use-after-free was found in bq24190_remove in drivers/power/supply/bq24190_charger.c. It could allow a local attacker to crash the system due to a race condition.

Published: 2023-05-22Modified: 2025-03-18
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3338
MEDIUM6.5

A null pointer dereference flaw was found in the Linux kernel's DECnet networking protocol. This issue could allow a remote user to crash the system.

Published: 2023-06-30Modified: 2024-11-21
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3358
MEDIUM5.5

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.

Published: 2023-06-28Modified: 2025-03-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3359
MEDIUM5.5

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.

Published: 2023-06-28Modified: 2025-03-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3389
HIGH7.8

A use-after-free vulnerability in the Linux Kernel io_uring subsystem can be exploited to achieve local privilege escalation. Racing a io_uring cancel poll request with a linked timeout can cause a UAF in a hrtimer. We recommend upgrading past commit ef7dfac51d8ed961b742218f526bd589f3900a59 (4716c73b188566865bdd79c3a6709696a224ac04 for 5.10 stable and 0e388fce7aec40992eadee654193cad345d62663 for 5.15 stable).

Published: 2023-06-28Modified: 2025-02-13
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-33951
MEDIUM5.3

A race condition vulnerability was found in the vmwgfx driver in the Linux kernel. The flaw exists within the handling of GEM objects. The issue results from improper locking when performing operations on an object. This flaw allows a local privileged user to disclose information in the context of the kernel.

Published: 2023-07-24Modified: 2026-02-18
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N
References
CVE-2023-33952
MEDIUM6.7

A double-free vulnerability was found in handling vmw_buffer_object objects in the vmwgfx driver in the Linux kernel. This issue occurs due to the lack of validating the existence of an object prior to performing further free operations on the object, which may allow a local privileged user to escalate privileges and execute code in the context of the kernel.

Published: 2023-07-24Modified: 2024-11-21
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-34256
MEDIUM5.5

An issue was discovered in the Linux kernel before 6.3.3. There is an out-of-bounds read in crc16 in lib/crc16.c when called from fs/ext4/super.c because ext4_group_desc_csum does not properly check an offset. NOTE: this is disputed by third parties because the kernel is not intended to defend against attackers with the stated "When modifying the block device while it is mounted by the filesystem" access.

Published: 2023-05-31Modified: 2025-03-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3567
HIGH7.1

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.

Published: 2023-07-24Modified: 2024-11-21
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-35823
HIGH7.0

An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in saa7134_finidev in drivers/media/pci/saa7134/saa7134-core.c.

Published: 2023-06-18Modified: 2025-05-05
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-35824
HIGH7.0

An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in dm1105_remove in drivers/media/pci/dm1105/dm1105.c.

Published: 2023-06-18Modified: 2025-05-05
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-35827
HIGH7.0

An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c.

Published: 2023-06-18Modified: 2024-11-21
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-3609
HIGH7.8

A use-after-free vulnerability in the Linux kernel's net/sched: cls_u32 component can be exploited to achieve local privilege escalation. If tcf_change_indev() fails, u32_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability. We recommend upgrading past commit 04c55383fa5689357bcdd2c8036725a55ed632bc.

Published: 2023-07-21Modified: 2025-02-13
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-37453
MEDIUM4.6

An issue was discovered in the USB subsystem in the Linux kernel through 6.4.2. There is an out-of-bounds and crash in read_descriptors in drivers/usb/core/sysfs.c.

Published: 2023-07-06Modified: 2025-05-05
CVSS 3.xMEDIUM 4.6
CVSS:3.x/CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-37454
MEDIUM5.5

An issue was discovered in the Linux kernel through 6.4.2. A crafted UDF filesystem image causes a use-after-free write operation in the udf_put_super and udf_close_lvid functions in fs/udf/super.c. NOTE: the suse.com reference has a different perspective about this.

Published: 2023-07-06Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-38409
MEDIUM5.5

An issue was discovered in set_con2fb_map in drivers/video/fbdev/core/fbcon.c in the Linux kernel before 6.2.12. Because an assignment occurs only for the first vc, the fbcon_registered_fb and fbcon_display arrays can be desynchronized in fbcon_mode_deleted (the con2fb_map points at the old fb_info).

Published: 2023-07-17Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-3863
MEDIUM4.1

A use-after-free flaw was found in nfc_llcp_find_local in net/nfc/llcp_core.c in NFC in the Linux kernel. This flaw allows a local user with special privileges to impact a kernel information leak issue.

Published: 2023-07-24Modified: 2024-11-21
CVSS 3.xMEDIUM 4.1
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
References
CVE-2023-39189
MEDIUM6.0

A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnl_osf_add_callback function did not validate the user mode controlled opt_num field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

Published: 2023-10-09Modified: 2024-11-21
CVSS 3.xMEDIUM 6.0
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-39191
HIGH8.2

An improper input validation flaw was found in the eBPF subsystem in the Linux kernel. The issue occurs due to a lack of proper validation of dynamic pointers within user-supplied eBPF programs prior to executing them. This may allow an attacker with CAP_BPF privileges to escalate privileges and execute arbitrary code in the context of the kernel.

Published: 2023-10-04Modified: 2024-11-21
CVSS 3.xHIGH 8.2
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
References
CVE-2023-39192
MEDIUM6.0

A flaw was found in the Netfilter subsystem in the Linux kernel. The xt_u32 module did not validate the fields in the xt_u32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds read by setting the size fields with a value beyond the array boundaries, leading to a crash or information disclosure.

Published: 2023-10-09Modified: 2024-11-21
CVSS 3.xMEDIUM 6.0
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-39193
MEDIUM6.0

A flaw was found in the Netfilter subsystem in the Linux kernel. The sctp_mt_check did not validate the flag_count field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

Published: 2023-10-09Modified: 2024-11-21
CVSS 3.xMEDIUM 6.0
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-39194
MEDIUM4.4

A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure.

Published: 2023-10-09Modified: 2024-11-21
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
References
CVE-2023-39198
MEDIUM6.4

A race condition was found in the QXL driver in the Linux kernel. The qxl_mode_dumb_create() function dereferences the qobj returned by the qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. This flaw allows an attacker to guess the returned handle value and trigger a use-after-free issue, potentially leading to a denial of service or privilege escalation.

Published: 2023-11-09Modified: 2026-03-24
CVSS 3.xMEDIUM 6.4
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-40791
MEDIUM6.3

extract_user_to_sg in lib/scatterlist.c in the Linux kernel before 6.4.12 fails to unpin pages in a certain situation, as demonstrated by a WARNING for try_grab_page.

Published: 2023-10-16Modified: 2024-11-21
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2023-4132
MEDIUM5.5

A use-after-free vulnerability was found in the siano smsusb module in the Linux kernel. The bug occurs during device initialization when the siano device is plugged in. This flaw allows a local user to crash the system, causing a denial of service condition.

Published: 2023-08-03Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-4133
MEDIUM5.5

A use-after-free vulnerability was found in the cxgb4 driver in the Linux kernel. The bug occurs when the cxgb4 device is detaching due to a possible rearming of the flower_stats_timer from the work queue. This flaw allows a local user to crash the system, causing a denial of service condition.

Published: 2023-08-03Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-4134
MEDIUM5.5

A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service.

Published: 2024-11-14Modified: 2024-11-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-4194
MEDIUM5.5

A flaw was found in the Linux kernel's TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to not be accurate.

Published: 2023-08-07Modified: 2026-03-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
References
CVE-2023-4244
HIGH7.0

A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability. We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8.

Published: 2023-09-06Modified: 2025-02-13
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-4273
MEDIUM6.7

A flaw was found in the exFAT driver of the Linux kernel. The vulnerability exists in the implementation of the file name reconstruction function, which is responsible for reading file name entries from a directory index and merging file name parts belonging to one file into a single long file name. Since the file name characters are copied into a stack variable, a local privileged attacker could use this flaw to overflow the kernel stack.

Published: 2023-08-09Modified: 2024-11-21
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-42752
MEDIUM5.5

An integer overflow flaw was found in the Linux kernel. This issue leads to the kernel allocating `skb_shared_info` in the userspace, which is exploitable in systems without SMAP protection since `skb_shared_info` contains references to function pointers.

Published: 2023-10-13Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-42754
MEDIUM5.5

A NULL pointer dereference flaw was found in the Linux kernel ipv4 stack. The socket buffer (skb) was assumed to be associated with a device before calling __ip_options_compile, which is not always the case if the skb is re-routed by ipvs. This issue may allow a local user with CAP_NET_ADMIN privileges to crash the system.

Published: 2023-10-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-42755
MEDIUM5.5

A flaw was found in the IPv4 Resource Reservation Protocol (RSVP) classifier in the Linux kernel. The xprt pointer may go beyond the linear part of the skb, leading to an out-of-bounds read in the `rsvp_classify` function. This issue may allow a local user to crash the system and cause a denial of service.

Published: 2023-10-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-42756
MEDIUM4.7

A flaw was found in the Netfilter subsystem of the Linux kernel. A race condition between IPSET_CMD_ADD and IPSET_CMD_SWAP can lead to a kernel panic due to the invocation of `__ip_set_put` on a wrong `set`. This issue may allow a local user to crash the system.

Published: 2023-09-28Modified: 2024-11-21
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-4458
HIGH7.5

A flaw was found within the parsing of extended attributes in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.

Published: 2024-11-14Modified: 2025-08-19
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
References
CVE-2023-4569
MEDIUM5.5

A memory leak flaw was found in nft_set_catchall_flush in net/netfilter/nf_tables_api.c in the Linux Kernel. This issue may allow a local attacker to cause double-deactivations of catchall elements, which can result in a memory leak.

Published: 2023-08-28Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-45862
MEDIUM5.5

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.

Published: 2023-10-14Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-45863
MEDIUM6.4

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.

Published: 2023-10-14Modified: 2024-11-21
CVSS 3.xMEDIUM 6.4
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-4611
MEDIUM6.3

A use-after-free flaw was found in mm/mempolicy.c in the memory management subsystem in the Linux Kernel. This issue is caused by a race between mbind() and VMA-locked page fault, and may allow a local attacker to crash the system or lead to a kernel information leak.

Published: 2023-08-29Modified: 2024-11-21
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-46343
MEDIUM5.5

In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c.

Published: 2024-01-23Modified: 2025-06-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-46813
HIGH7.0

An issue was discovered in the Linux kernel before 6.5.9, exploitable by local users with userspace access to MMIO registers. Incorrect access checking in the #VC handler and instruction emulation of the SEV-ES emulation of MMIO accesses could lead to arbitrary write access to kernel memory (and thus privilege escalation). This depends on a race condition through which userspace can replace an instruction before the #VC handler reads it.

Published: 2023-10-27Modified: 2026-02-25
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-46862
MEDIUM4.7

An issue was discovered in the Linux kernel through 6.5.9. During a race with SQ thread exit, an io_uring/fdinfo.c io_uring_show_fdinfo NULL pointer dereference can occur.

Published: 2023-10-29Modified: 2024-11-21
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-47233
MEDIUM4.3

The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.

Published: 2023-11-03Modified: 2025-03-06
CVSS 3.xMEDIUM 4.3
CVSS:3.x/CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-5090
MEDIUM5.5

A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.

Published: 2023-11-06Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-51042
HIGH7.8

In the Linux kernel before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free.

Published: 2024-01-23Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-51043
HIGH7.0

In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload.

Published: 2024-01-23Modified: 2024-11-21
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-51780
HIGH7.0

An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition.

Published: 2024-01-11Modified: 2024-11-21
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-51781
HIGH7.0

An issue was discovered in the Linux kernel before 6.6.8. atalk_ioctl in net/appletalk/ddp.c has a use-after-free because of an atalk_recvmsg race condition.

Published: 2024-01-11Modified: 2024-11-21
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-51782
HIGH7.0

An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition.

Published: 2024-01-11Modified: 2024-11-21
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52340
HIGH7.5

The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket.

Published: 2024-07-05Modified: 2025-11-04
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52429
MEDIUM5.5

dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count.

Published: 2024-02-12Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52434
HIGH8.0

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential OOBs in smb2_parse_contexts() Validate offsets and lengths before dereferencing create contexts in smb2_parse_contexts(). This fixes following oops when accessing invalid create contexts from server: BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e

Published: 2024-02-20Modified: 2025-01-17
CVSS 3.xHIGH 8.0
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52435
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: prevent mss overflow in skb_segment() Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily : mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1] general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109 ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53 __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated---

Published: 2024-02-20Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52452
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead. This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue. A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.

Published: 2024-02-22Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52591
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: reiserfs: Avoid touching renamed directory if parent does not change The VFS will not be locking moved directory if its parent does not change. Change reiserfs rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem.

Published: 2024-03-06Modified: 2025-03-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52596
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix out of bounds access for empty sysctl registers When registering tables to the sysctl subsystem there is a check to see if header is a permanently empty directory (used for mounts). This check evaluates the first element of the ctl_table. This results in an out of bounds evaluation when registering empty directories. The function register_sysctl_mount_point now passes a ctl_table of size 1 instead of size 0. It now relies solely on the type to identify a permanently empty register. Make sure that the ctl_table has at least one element before testing for permanent emptiness.

Published: 2024-03-06Modified: 2025-02-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52616
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init When the mpi_ec_ctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately.

Published: 2024-03-18Modified: 2025-03-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52620
LOW2.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow timeout for anonymous sets Never used from userspace, disallow these parameters.

Published: 2024-03-21Modified: 2025-09-16
CVSS 3.xLOW 2.5
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
References
CVE-2023-52629
HIGH8.4

In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations.

Published: 2024-03-29Modified: 2025-04-08
CVSS 3.xHIGH 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52631
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix an NULL dereference bug The issue here is when this is called from ntfs_load_attr_list(). The "size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow on a 64bit systems but on 32bit systems the "+ 1023" can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZERO_SIZE_PTR and then the memcpy() will crash with an Oops on the next line.

Published: 2024-04-02Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52637
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets. Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350 CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ? __kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280 [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [can_raw] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] can_rcv_filter+0x11f/0x350 [can] can_receive+0x12f/0x190 [can] ? __pfx_can_rcv+0x10/0x10 [can] can_rcv+0xdd/0x130 [can] ? __pfx_can_rcv+0x10/0x10 [can] __netif_receive_skb_one_core+0x13d/0x150 ? __pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20 ? _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260 __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ? __pfx_can_send+0x10/0x10 [can] ? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw] ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] ? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ? __rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ? __pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70 __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 348: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30 __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0 __kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52638
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change]

Published: 2024-04-03Modified: 2025-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52639
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: fix race during shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm; Let children inherit the private field of the parent.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52640
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix oob in ntfs_listxattr The length of name cannot exceed the space occupied by ea.

Published: 2024-04-03Modified: 2025-02-27
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-52641
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame() It is preferable to exit through the out: label because internal debugging functions are located there.

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52642
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: media: rc: bpf attach/detach requires write permission Note that bpf attach/detach also requires CAP_NET_ADMIN.

Published: 2024-04-17Modified: 2025-03-27
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52643
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: iio: core: fix memleak in iio_device_register_sysfs When iio_device_register_sysfs_group() fails, we should free iio_dev_opaque->chan_attr_group.attrs to prevent potential memleak.

Published: 2024-04-17Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52644
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated---

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2023-52645
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: fix race conditions with genpd If the power domains are registered first with genpd and *after that* the driver attempts to power them on in the probe sequence, then it is possible that a race condition occurs if genpd tries to power them on in the same time. The same is valid for powering them off before unregistering them from genpd. Attempt to fix race conditions by first removing the domains from genpd and *after that* powering down domains. Also first power up the domains and *after that* register them to genpd.

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52648
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Unmap the surface before resetting it on a plane state Switch to a new plane state requires unreferencing of all held surfaces. In the work required for mob cursors the mapped surfaces started being cached but the variable indicating whether the surface is currently mapped was not being reset. This leads to crashes as the duplicated state, incorrectly, indicates the that surface is mapped even when no surface is present. That's because after unreferencing the surface it's perfectly possible for the plane to be backed by a bo instead of a surface. Reset the surface mapped flag when unreferencing the plane state surface to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920 R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00 FS: 00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] drm_atomic_helper_cleanup_planes+0x9b/0xc0 commit_tail+0xd1/0x130 drm_atomic_helper_commit+0x11a/0x140 drm_atomic_commit+0x97/0xd0 ? __pfx___drm_printfn_info+0x10/0x10 drm_atomic_helper_update_plane+0xf5/0x160 drm_mode_cursor_universal+0x10e/0x270 drm_mode_cursor_common+0x102/0x230 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 drm_ioctl_kernel+0xb2/0x110 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 ? __pfx_drm_ioctl+0x10/0x10 vmw_generic_ioctl+0xa4/0x110 [vmwgfx] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x61/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40 ? do_syscall_64+0x70/0xe0 ? exc_page_fault+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f1e93f279ed Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f> RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279ed RDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015 RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007 R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0 R13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790 Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine> CR2: 0000000000000028 ---[ end trace 0000000000000000 ]--- RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143 ---truncated---

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52650
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/tegra: dsi: Add missing check for of_find_device_by_node Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52652
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: NTB: fix possible name leak in ntb_register_device() If device_register() fails in ntb_register_device(), the device name allocated by dev_set_name() should be freed. As per the comment in device_register(), callers should use put_device() to give up the reference in the error path. So fix this by calling put_device() in the error path so that the name can be freed in kobject_cleanup(). As a result of this, put_device() in the error path of ntb_register_device() is removed and the actual error is returned. [mani: reworded commit message]

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52653
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix a memleak in gss_import_v2_context The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error. Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation.

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52656
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: io_uring: drop any code related to SCM_RIGHTS This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it.

Published: 2024-05-14Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52657
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Revert "drm/amd/pm: resolve reboot exception for si oland" This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86. This causes hangs on SI when DC is enabled and errors on driver reboot and power off cycles.

Published: 2024-05-17Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52658
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Revert "net/mlx5: Block entering switchdev mode with ns inconsistency" This reverts commit 662404b24a4c4d839839ed25e3097571f5938b9b. The revert is required due to the suspicion it is not good for anything and cause crash.

Published: 2024-05-17Modified: 2026-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52660
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ handling due to shared interrupts The driver requests the interrupts as IRQF_SHARED, so the interrupt handlers can be called at any time. If such a call happens while the ISP is powered down, the SoC will hang as the driver tries to access the ISP registers. This can be reproduced even without the platform sharing the IRQ line: Enable CONFIG_DEBUG_SHIRQ and unload the driver, and the board will hang. Fix this by adding a new field, 'irqs_enabled', which is used to bail out from the interrupt handler when the ISP is not operational.

Published: 2024-05-17Modified: 2025-09-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52661
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe() If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be undone. Add the missing clk_put and a new 'put_pll_d_out0' label in the error handling path, and use it.

Published: 2024-05-17Modified: 2025-09-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52662
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node When ida_alloc_max fails, resources allocated before should be freed, including *res allocated by kmalloc and ttm_resource_init.

Published: 2024-05-17Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52671
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix hang/underflow when transitioning to ODM4:1 [Why] Under some circumstances, disabling an OPTC and attempting to reclaim its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs not being properly disconnected from the disabled OPTC. [How] Ensure that all OPPs are unassigned from an OPTC when it gets disabled.

Published: 2024-05-17Modified: 2025-09-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52676
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain, instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset. The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset either comes from an instruction (in which case it is 16 bit), from another register (in which case the caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being up to an u32, it appears that we were open to overflowing the `int`s which were currently used for arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904

Published: 2024-05-17Modified: 2025-09-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52699
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock).

Published: 2024-05-19Modified: 2025-04-04
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2023-52751
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in smb2_query_info_compound() The following UAF was triggered when running fstests generic/072 with KASAN enabled against Windows Server 2022 and mount options 'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfs_io/27534 CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs] ? smb2_query_info_compound+0x423/0x6d0 [cifs] smb2_query_info_compound+0x423/0x6d0 [cifs] ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __stack_depot_save+0x39/0x480 ? kasan_save_stack+0x33/0x60 ? kasan_set_track+0x25/0x30 ? ____kasan_slab_free+0x126/0x170 smb2_queryfs+0xc2/0x2c0 [cifs] ? __pfx_smb2_queryfs+0x10/0x10 [cifs] ? __pfx___lock_acquire+0x10/0x10 smb311_queryfs+0x210/0x220 [cifs] ? __pfx_smb311_queryfs+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __lock_acquire+0x480/0x26c0 ? lock_release+0x1ed/0x640 ? srso_alias_return_thunk+0x5/0x7f ? do_raw_spin_unlock+0x9b/0x100 cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 ? __pfx___do_sys_fstatfs+0x10/0x10 ? srso_alias_return_thunk+0x5/0x7f ? lockdep_hardirqs_on_prepare+0x136/0x200 ? srso_alias_return_thunk+0x5/0x7f do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 open_cached_dir+0x71b/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] smb311_queryfs+0x210/0x220 [cifs] cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 ____kasan_slab_free+0x126/0x170 slab_free_freelist_hook+0xd0/0x1e0 __kmem_cache_free+0x9d/0x1b0 open_cached_dir+0xff5/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] This is a race between open_cached_dir() and cached_dir_lease_break() where the cache entry for the open directory handle receives a lease break while creating it. And before returning from open_cached_dir(), we put the last reference of the new @cfid because of !@cfid->has_lease. Besides the UAF, while running xfstests a lot of missed lease breaks have been noticed in tests that run several concurrent statfs(2) calls on those cached fids CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS: Dump pending requests: CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ... To fix both, in open_cached_dir() ensure that @cfid->has_lease is set right before sending out compounded request so that any potential lease break will be get processed by demultiplex thread while we're still caching @cfid. And, if open failed for some reason, re-check @cfid->has_lease to decide whether or not put lease reference.

Published: 2024-05-21Modified: 2025-01-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52760
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.

Published: 2024-05-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52761
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: riscv: VMAP_STACK overflow detection thread-safe commit 31da94c25aea ("riscv: add VMAP_STACK overflow detection") added support for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to `shadow_stack` temporarily before switching finally to per-cpu `overflow_stack`. If two CPUs/harts are racing and end up in over flowing kernel stack, one or both will end up corrupting each other state because `shadow_stack` is not per-cpu. This patch optimizes per-cpu overflow stack switch by directly picking per-cpu `overflow_stack` and gets rid of `shadow_stack`. Following are the changes in this patch - Defines an asm macro to obtain per-cpu symbols in destination register. - In entry.S, when overflow is detected, per-cpu overflow stack is located using per-cpu asm macro. Computing per-cpu symbol requires a temporary register. x31 is saved away into CSR_SCRATCH (CSR_SCRATCH is anyways zero since we're in kernel). Please see Links for additional relevant disccussion and alternative solution. Tested by `echo EXHAUST_STACK > /sys/kernel/debug/provoke-crash/DIRECT` Kernel crash log below Insufficient stack space to handle exception!/debug/provoke-crash/DIRECT Task stack: [0xff20000010a98000..0xff20000010a9c000] Overflow stack: [0xff600001f7d98370..0xff600001f7d99370] CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34 Hardware name: riscv-virtio,qemu (DT) epc : __memset+0x60/0xfc ra : recursive_loop+0x48/0xc6 [lkdtm] epc : ffffffff808de0e4 ra : ffffffff0163a752 sp : ff20000010a97e80 gp : ffffffff815c0330 tp : ff600000820ea280 t0 : ff20000010a97e88 t1 : 000000000000002e t2 : 3233206874706564 s0 : ff20000010a982b0 s1 : 0000000000000012 a0 : ff20000010a97e88 a1 : 0000000000000000 a2 : 0000000000000400 a3 : ff20000010a98288 a4 : 0000000000000000 a5 : 0000000000000000 a6 : fffffffffffe43f0 a7 : 00007fffffffffff s2 : ff20000010a97e88 s3 : ffffffff01644680 s4 : ff20000010a9be90 s5 : ff600000842ba6c0 s6 : 00aaaaaac29e42b0 s7 : 00fffffff0aa3684 s8 : 00aaaaaac2978040 s9 : 0000000000000065 s10: 00ffffff8a7cad10 s11: 00ffffff8a76a4e0 t3 : ffffffff815dbaf4 t4 : ffffffff815dbaf4 t5 : ffffffff815dbab8 t6 : ff20000010a9bb48 status: 0000000200000120 badaddr: ff20000010a97e88 cause: 000000000000000f Kernel panic - not syncing: Kernel stack overflow CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34 Hardware name: riscv-virtio,qemu (DT) Call Trace: [] dump_backtrace+0x30/0x38 [] show_stack+0x40/0x4c [] dump_stack_lvl+0x44/0x5c [] dump_stack+0x18/0x20 [] panic+0x126/0x2fe [] walk_stackframe+0x0/0xf0 [] recursive_loop+0x48/0xc6 [lkdtm] SMP: stopping secondary CPUs ---[ end Kernel panic - not syncing: Kernel stack overflow ]---

Published: 2024-05-21Modified: 2025-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52770
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: split initial and dynamic conditions for extent_cache Let's allocate the extent_cache tree without dynamic conditions to avoid a missing condition causing a panic as below. # create a file w/ a compressed flag # disable the compression # panic while updating extent_cache F2FS-fs (dm-64): Swapfile: last extent is not aligned to section F2FS-fs (dm-64): Swapfile (3) is not align to section: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N) Adding 124996k swap on ./swap-file. Priority:0 extents:2 across:17179494468k ================================================================== BUG: KASAN: null-ptr-deref in instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] BUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] BUG: KASAN: null-ptr-deref in queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] BUG: KASAN: null-ptr-deref in __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] BUG: KASAN: null-ptr-deref in _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 Write of size 4 at addr 0000000000000030 by task syz-executor154/3327 CPU: 0 PID: 3327 Comm: syz-executor154 Tainted: G O 5.10.185 #1 Hardware name: emulation qemu-x86/qemu-x86, BIOS 2023.01-21885-gb3cc1cd24d 01/01/2023 Call Trace: __dump_stack out/common/lib/dump_stack.c:77 [inline] dump_stack_lvl+0x17e/0x1c4 out/common/lib/dump_stack.c:118 __kasan_report+0x16c/0x260 out/common/mm/kasan/report.c:415 kasan_report+0x51/0x70 out/common/mm/kasan/report.c:428 kasan_check_range+0x2f3/0x340 out/common/mm/kasan/generic.c:186 __kasan_check_write+0x14/0x20 out/common/mm/kasan/shadow.c:37 instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 __drop_extent_tree+0xdf/0x2f0 out/common/fs/f2fs/extent_cache.c:1155 f2fs_drop_extent_tree+0x17/0x30 out/common/fs/f2fs/extent_cache.c:1172 f2fs_insert_range out/common/fs/f2fs/file.c:1600 [inline] f2fs_fallocate+0x19fd/0x1f40 out/common/fs/f2fs/file.c:1764 vfs_fallocate+0x514/0x9b0 out/common/fs/open.c:310 ksys_fallocate out/common/fs/open.c:333 [inline] __do_sys_fallocate out/common/fs/open.c:341 [inline] __se_sys_fallocate out/common/fs/open.c:339 [inline] __x64_sys_fallocate+0xb8/0x100 out/common/fs/open.c:339 do_syscall_64+0x35/0x50 out/common/arch/x86/entry/common.c:46

Published: 2024-05-21Modified: 2025-01-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52771
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix delete_endpoint() vs parent unregistration race The CXL subsystem, at cxl_mem ->probe() time, establishes a lineage of ports (struct cxl_port objects) between an endpoint and the root of a CXL topology. Each port including the endpoint port is attached to the cxl_port driver. Given that setup, it follows that when either any port in that lineage goes through a cxl_port ->remove() event, or the memdev goes through a cxl_mem ->remove() event. The hierarchy below the removed port, or the entire hierarchy if the memdev is removed needs to come down. The delete_endpoint() callback is careful to check whether it is being called to tear down the hierarchy, or if it is only being called to teardown the memdev because an ancestor port is going through ->remove(). That care needs to take the device_lock() of the endpoint's parent. Which requires 2 bugs to be fixed: 1/ A reference on the parent is needed to prevent use-after-free scenarios like this signature: BUG: spinlock bad magic on CPU#0, kworker/u56:0/11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 05/24/2023 Workqueue: cxl_port detach_memdev [cxl_core] RIP: 0010:spin_bug+0x65/0xa0 Call Trace: do_raw_spin_lock+0x69/0xa0 __mutex_lock+0x695/0xb80 delete_endpoint+0xad/0x150 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 detach_memdev+0x15/0x20 [cxl_core] process_one_work+0x1e3/0x4c0 worker_thread+0x1dd/0x3d0 2/ In the case of RCH topologies, the parent device that needs to be locked is not always @port->dev as returned by cxl_mem_find_port(), use endpoint->dev.parent instead.

Published: 2024-05-21Modified: 2025-09-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52797
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drivers: perf: Check find_first_bit() return value We must check the return value of find_first_bit() before using the return value as an index array since it happens to overflow the array and then panic: [ 107.318430] Kernel BUG [#1] [ 107.319434] CPU: 3 PID: 1238 Comm: kill Tainted: G E 6.6.0-rc6ubuntu-defconfig #2 [ 107.319465] Hardware name: riscv-virtio,qemu (DT) [ 107.319551] epc : pmu_sbi_ovf_handler+0x3a4/0x3ae [ 107.319840] ra : pmu_sbi_ovf_handler+0x52/0x3ae [ 107.319868] epc : ffffffff80a0a77c ra : ffffffff80a0a42a sp : ffffaf83fecda350 [ 107.319884] gp : ffffffff823961a8 tp : ffffaf8083db1dc0 t0 : ffffaf83fecda480 [ 107.319899] t1 : ffffffff80cafe62 t2 : 000000000000ff00 s0 : ffffaf83fecda520 [ 107.319921] s1 : ffffaf83fecda380 a0 : 00000018fca29df0 a1 : ffffffffffffffff [ 107.319936] a2 : 0000000001073734 a3 : 0000000000000004 a4 : 0000000000000000 [ 107.319951] a5 : 0000000000000040 a6 : 000000001d1c8774 a7 : 0000000000504d55 [ 107.319965] s2 : ffffffff82451f10 s3 : ffffffff82724e70 s4 : 000000000000003f [ 107.319980] s5 : 0000000000000011 s6 : ffffaf8083db27c0 s7 : 0000000000000000 [ 107.319995] s8 : 0000000000000001 s9 : 00007fffb45d6558 s10: 00007fffb45d81a0 [ 107.320009] s11: ffffaf7ffff60000 t3 : 0000000000000004 t4 : 0000000000000000 [ 107.320023] t5 : ffffaf7f80000000 t6 : ffffaf8000000000 [ 107.320037] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 107.320081] [] pmu_sbi_ovf_handler+0x3a4/0x3ae [ 107.320112] [] handle_percpu_devid_irq+0x9e/0x1a0 [ 107.320131] [] generic_handle_domain_irq+0x28/0x36 [ 107.320148] [] riscv_intc_irq+0x36/0x4e [ 107.320166] [] handle_riscv_irq+0x54/0x86 [ 107.320189] [] do_irq+0x64/0x96 [ 107.320271] Code: 85a6 855e b097 ff7f 80e7 9220 b709 9002 4501 bbd9 (9002) 6097 [ 107.320585] ---[ end trace 0000000000000000 ]--- [ 107.320704] Kernel panic - not syncing: Fatal exception in interrupt [ 107.320775] SMP: stopping secondary CPUs [ 107.321219] Kernel Offset: 0x0 from 0xffffffff80000000 [ 107.333051] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

Published: 2024-05-21Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52812
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd: check num of link levels when update pcie param In SR-IOV environment, the value of pcie_table->num_of_link_levels will be 0, and num_of_levels - 1 will cause array index out of bounds

Published: 2024-05-21Modified: 2025-11-25
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52827
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats() len is extracted from HTT message and could be an unexpected value in case errors happen, so add validation before using to avoid possible out-of-bound read in the following message iteration and parsing. The same issue also applies to ppdu_info->ppdu_stats.common.num_users, so validate it before using too. These are found during code review. Compile test only.

Published: 2024-05-21Modified: 2024-11-21
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-52857
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix coverity issue with unintentional integer overflow 1. Instead of multiplying 2 variable of different types. Change to assign a value of one variable and then multiply the other variable. 2. Add a int variable for multiplier calculation instead of calculating different types multiplier with dma_addr_t variable directly.

Published: 2024-05-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52880
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that.

Published: 2024-05-24Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52882
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52884
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: Input: cyapa - add missing input core locking to suspend/resume functions Grab input->mutex during suspend/resume functions like it is done in other input drivers. This fixes the following warning during system suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]--- ... ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]---

Published: 2024-06-21Modified: 2025-03-24
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52887
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52888
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Only free buffer VA that is not NULL In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice. We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings.

Published: 2024-07-30Modified: 2025-10-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52889
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: apparmor: Fix null pointer deref when receiving skb during sock creation The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SK_CTX(sk)->label is updated in apparmor_socket_post_create(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set. BUG: kernel NULL pointer dereference, address: 000000000000004c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020 RIP: 0010:aa_label_next_confined+0xb/0x40 Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2 RSP: 0018:ffffa92940003b08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002 R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? aa_label_next_confined+0xb/0x40 apparmor_secmark_check+0xec/0x330 security_sock_rcv_skb+0x35/0x50 sk_filter_trim_cap+0x47/0x250 sock_queue_rcv_skb_reason+0x20/0x60 raw_rcv+0x13c/0x210 raw_local_deliver+0x1f3/0x250 ip_protocol_deliver_rcu+0x4f/0x2f0 ip_local_deliver_finish+0x76/0xa0 __netif_receive_skb_one_core+0x89/0xa0 netif_receive_skb+0x119/0x170 ? __netdev_alloc_skb+0x3d/0x140 vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] __napi_poll+0x28/0x1b0 net_rx_action+0x2a4/0x380 __do_softirq+0xd1/0x2c8 __irq_exit_rcu+0xbb/0xf0 common_interrupt+0x86/0xa0 asm_common_interrupt+0x26/0x40 RIP: 0010:apparmor_socket_post_create+0xb/0x200 Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 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 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48 RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286 RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003 R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748 ? __pfx_apparmor_socket_post_create+0x10/0x10 security_socket_post_create+0x4b/0x80 __sock_create+0x176/0x1f0 __sys_socket+0x89/0x100 __x64_sys_socket+0x17/0x20 do_syscall_64+0x5d/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52916
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: media: aspeed: Fix memory overwrite if timing is 1600x900 When capturing 1600x900, system could crash when system memory usage is tight. The way to reproduce this issue: 1. Use 1600x900 to display on host 2. Mount ISO through 'Virtual media' on OpenBMC's web 3. Run script as below on host to do sha continuously #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done 4. Open KVM on OpenBMC's web The size of macro block captured is 8x8. Therefore, we should make sure the height of src-buf is 8 aligned to fix this issue.

Published: 2024-09-06Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52918
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL.

Published: 2024-10-22Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-52927
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.

Published: 2025-03-14Modified: 2025-12-31
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-52999
HIGH7.8

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: dump_stack_lvl+0x6a/0x9f print_address_description.constprop.0+0x86/0x2b5 print_report+0x11b/0x1fb kasan_report+0x87/0xc0 ops_init+0x2de/0x320 register_pernet_operations+0x2e4/0x750 register_pernet_subsys+0x24/0x40 tcf_register_action+0x9f/0x560 do_one_initcall+0xf9/0x570 do_init_module+0x190/0x650 load_module+0x1fa5/0x23c0 __do_sys_finit_module+0x10d/0x1b0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f42518f778d Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d RDX: 0000000000000000 RSI: 00005568ef41d796 RDI: 0000000000000003 RBP: 00005568ef41d796 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000 R13: 00005568ef7f7d30 R14: 0000000000040000 R15: 0000000000000000 This change addresses the issue by skipping the gen pointer de-reference in the mentioned error-path. Found by code inspection and verified with explicit error injection on a kasan-enabled kernel.

Published: 2025-03-27Modified: 2025-04-01
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-53012
MEDIUM5.5

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.

Published: 2025-03-27Modified: 2025-10-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53071
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: do not run mt76_unregister_device() on unregistered hw Trying to probe a mt7921e pci card without firmware results in a successful probe where ieee80211_register_hw hasn't been called. When removing the driver, ieee802111_unregister_hw is called unconditionally leading to a kernel NULL pointer dereference. Fix the issue running mt76_unregister_device routine just for registered hw.

Published: 2025-05-02Modified: 2025-11-12
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53149
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid deadlock in fs reclaim with page writeback Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like: CPU0 CPU1 ext4_writepages() percpu_down_read(sbi->s_writepages_rwsem); ext4_change_inode_journal_flag() percpu_down_write(sbi->s_writepages_rwsem); - blocks, all readers block from now on ext4_do_writepages() ext4_init_io_end() kmem_cache_zalloc(io_end_cachep, GFP_KERNEL) fs_reclaim frees dentry... dentry_unlink_inode() iput() - last ref => iput_final() - inode dirty => write_inode_now()... ext4_writepages() tries to acquire sbi->s_writepages_rwsem and blocks forever Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.

Published: 2025-09-15Modified: 2025-11-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53151
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: md/raid10: prevent soft lockup while flush writes Currently, there is no limit for raid1/raid10 plugged bio. While flushing writes, raid1 has cond_resched() while raid10 doesn't, and too many writes can cause soft lockup. Follow up soft lockup can be triggered easily with writeback test for raid10 with ramdisks: watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293] Call Trace: call_rcu+0x16/0x20 put_object+0x41/0x80 __delete_object+0x50/0x90 delete_object_full+0x2b/0x40 kmemleak_free+0x46/0xa0 slab_free_freelist_hook.constprop.0+0xed/0x1a0 kmem_cache_free+0xfd/0x300 mempool_free_slab+0x1f/0x30 mempool_free+0x3a/0x100 bio_free+0x59/0x80 bio_put+0xcf/0x2c0 free_r10bio+0xbf/0xf0 raid_end_bio_io+0x78/0xb0 one_write_done+0x8a/0xa0 raid10_end_write_request+0x1b4/0x430 bio_endio+0x175/0x320 brd_submit_bio+0x3b9/0x9b7 [brd] __submit_bio+0x69/0xe0 submit_bio_noacct_nocheck+0x1e6/0x5a0 submit_bio_noacct+0x38c/0x7e0 flush_pending_writes+0xf0/0x240 raid10d+0xac/0x1ed0 Fix the problem by adding cond_resched() to raid10 like what raid1 did. Note that unlimited plugged bio still need to be optimized, for example, in the case of lots of dirty pages writeback, this will take lots of memory and io will spend a long time in plug, hence io latency is bad.

Published: 2025-09-15Modified: 2025-11-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53194
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add length check in indx_get_root This adds a length check to guarantee the retrieved index root is legit. [ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320 [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 162.462609] Call Trace: [ 162.462954] [ 162.463276] dump_stack_lvl+0x49/0x63 [ 162.463822] print_report.cold+0xf5/0x689 [ 162.464608] ? unwind_get_return_address+0x3a/0x60 [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.466975] kasan_report+0xa7/0x130 [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0 [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.468536] __asan_load2+0x68/0x90 [ 162.468923] hdr_find_e.isra.0+0x10c/0x320 [ 162.469282] ? cmp_uints+0xe0/0xe0 [ 162.469557] ? cmp_sdh+0x90/0x90 [ 162.469864] ? ni_find_attr+0x214/0x300 [ 162.470217] ? ni_load_mi+0x80/0x80 [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.470931] ? ntfs_bread_run+0x190/0x190 [ 162.471307] ? indx_get_root+0xe4/0x190 [ 162.471556] ? indx_get_root+0x140/0x190 [ 162.471833] ? indx_init+0x1e0/0x1e0 [ 162.472069] ? fnd_clear+0x115/0x140 [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100 [ 162.472731] indx_find+0x184/0x470 [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0 [ 162.474704] ? do_syscall_64+0x3b/0x90 [ 162.474962] dir_search_u+0x196/0x2f0 [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450 [ 162.475661] ? ntfs_security_init+0x3d6/0x440 [ 162.475906] ? is_sd_valid+0x180/0x180 [ 162.476191] ntfs_extend_init+0x13f/0x2c0 [ 162.476496] ? ntfs_fix_post_read+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfs_fill_super+0x11e0/0x1b50 [ 162.477709] ? put_ntfs+0x1d0/0x1d0 [ 162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? set_blocksize+0x95/0x150 [ 162.478538] get_tree_bdev+0x232/0x370 [ 162.478789] ? put_ntfs+0x1d0/0x1d0 [ 162.479038] ntfs_fs_get_tree+0x15/0x20 [ 162.479374] vfs_get_tree+0x4c/0x130 [ 162.479729] path_mount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finish_automount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmem_cache_free+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] do_mount+0xd6/0xf0 [ 162.483264] ? path_mount+0xfe0/0xfe0 [ 162.484782] ? __kasan_check_write+0x14/0x20 [ 162.485593] __x64_sys_mount+0xca/0x110 [ 162.486024] do_syscall_64+0x3b/0x90 [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.487141] RIP: 0033:0x7f9d374e948a [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0 [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020 [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [ 162.493644] [ 162.493908] [ 162.494214] The buggy address belongs to the physical page: [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000 [ 162.500542] page dumped becau ---truncated---

Published: 2025-09-15Modified: 2025-12-02
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-53218
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Make it so that a waiting process can be aborted When sendmsg() creates an rxrpc call, it queues it to wait for a connection and channel to be assigned and then waits before it can start shovelling data as the encrypted DATA packet content includes a summary of the connection parameters. However, sendmsg() may get interrupted before a connection gets assigned and further sendmsg() calls will fail with EBUSY until an assignment is made. Fix this so that the call can at least be aborted without failing on EBUSY. We have to be careful here as sendmsg() mustn't be allowed to start the call timer if the call doesn't yet have a connection assigned as an oops may follow shortly thereafter.

Published: 2025-09-15Modified: 2026-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-53231
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: erofs: Fix detection of atomic context Current check for atomic context is not sufficient as z_erofs_decompressqueue_endio can be called under rcu lock from blk_mq_flush_plug_list(). See the stacktrace [1] In such case we should hand off the decompression work for async processing rather than trying to do sync decompression in current context. Patch fixes the detection by checking for rcu_read_lock_any_held() and while at it use more appropriate !in_task() check than in_atomic(). Background: Historically erofs would always schedule a kworker for decompression which would incur the scheduling cost regardless of the context. But z_erofs_decompressqueue_endio() may not always be in atomic context and we could actually benefit from doing the decompression in z_erofs_decompressqueue_endio() if we are in thread context, for example when running with dm-verity. This optimization was later added in patch [2] which has shown improvement in performance benchmarks. ============================================== [1] Problem stacktrace [name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291 [name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi [name:core&]preempt_count: 0, expected: 0 [name:core&]RCU nest depth: 1, expected: 0 CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1 Hardware name: MT6897 (DT) Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4 [2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/

Published: 2025-09-15Modified: 2026-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53261
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: coresight: Fix memory leak in acpi_buffer->pointer There are memory leaks reported by kmemleak: ... unreferenced object 0xffff00213c141000 (size 1024): comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight] ... The ACPI buffer memory (buf.pointer) should be freed. But the buffer is also used after returning from acpi_get_dsd_graph(). Move the temporary variables buf to acpi_coresight_parse_graph(), and free it before the function return to prevent memory leak.

Published: 2025-09-15Modified: 2026-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53292
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NULL dereference on q->elevator by checking it with lock.

Published: 2025-09-16Modified: 2026-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53336
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: ipu-bridge: Fix null pointer deref on SSDB/PLD parsing warnings When ipu_bridge_parse_rotation() and ipu_bridge_parse_orientation() run sensor->adev is not set yet. So if either of the dev_warn() calls about unknown values are hit this will lead to a NULL pointer deref. Set sensor->adev earlier, with a borrowed ref to avoid making unrolling on errors harder, to fix this.

Published: 2025-09-17Modified: 2026-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53353
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release() The memory manager IDR is currently destroyed when user releases the file descriptor. However, at this point the user context might be still held, and memory buffers might be still in use. Later on, calls to release those buffers will fail due to not finding their handles in the IDR, leading to a memory leak. To avoid this leak, split the IDR destruction from the memory manager fini, and postpone it to hpriv_release() when there is no user context and no buffers are used.

Published: 2025-09-17Modified: 2026-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53367
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: accel/habanalabs: fix mem leak in capture user mappings This commit fixes a memory leak caused when clearing the user_mappings info when a new context is opened immediately after user_mapping is captured and a hard reset is performed.

Published: 2025-09-17Modified: 2026-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53394
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix crash on regular rq reactivation When the regular rq is reactivated after the XSK socket is closed it could be reading stale cqes which eventually corrupts the rq. This leads to no more traffic being received on the regular rq and a crash on the next close or deactivation of the rq. Kal Cuttler Conely reported this issue as a crash on the release path when the xdpsock sample program is stopped (killed) and restarted in sequence while traffic is running. This patch flushes all cqes when during the rq flush. The cqe flushing is done in the reset state of the rq. mlx5e_rq_to_ready code is moved into the flush function to allow for this.

Published: 2025-09-18Modified: 2026-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53421
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats() When blkg_alloc() is called to allocate a blkcg_gq structure with the associated blkg_iostat_set's, there are 2 fields within blkg_iostat_set that requires proper initialization - blkg & sync. The former field was introduced by commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") while the later one was introduced by commit f73316482977 ("blk-cgroup: reimplement basic IO stats using cgroup rstat"). Unfortunately those fields in the blkg_iostat_set's are not properly re-initialized when they are cleared in v1's blkcg_reset_stats(). This can lead to a kernel panic due to NULL pointer access of the blkg pointer. The missing initialization of sync is less problematic and can be a problem in a debug kernel due to missing lockdep initialization. Fix these problems by re-initializing them after memory clearing.

Published: 2025-09-18Modified: 2026-04-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53424
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: fix of_iomap memory leak Smatch reports: drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn: 'base' from of_iomap() not released on lines: 496. This problem was also found in linux-next. In mtk_clk_simple_probe(), base is not released when handling errors if clk_data is not existed, which may cause a leak. So free_base should be added here to release base.

Published: 2025-09-18Modified: 2026-04-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53429
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't check PageError in __extent_writepage __extent_writepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O. Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in __extent_writepage by never leaking the error bit into the submission context.

Published: 2025-09-18Modified: 2026-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53447
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: f2fs: don't reset unchangable mount option in f2fs_remount() syzbot reports a bug as below: general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942 Call Trace: lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691 __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline] _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300 __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100 f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116 f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664 f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838 vfs_fallocate+0x54b/0x6b0 fs/open.c:324 ksys_fallocate fs/open.c:347 [inline] __do_sys_fallocate fs/open.c:355 [inline] __se_sys_fallocate fs/open.c:353 [inline] __x64_sys_fallocate+0xbd/0x100 fs/open.c:353 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is race condition as below: - since it tries to remount rw filesystem, so that do_remount won't call sb_prepare_remount_readonly to block fallocate, there may be race condition in between remount and fallocate. - in f2fs_remount(), default_options() will reset mount option to default one, and then update it based on result of parse_options(), so there is a hole which race condition can happen. Thread A Thread B - f2fs_fill_super - parse_options - clear_opt(READ_EXTENT_CACHE) - f2fs_remount - default_options - set_opt(READ_EXTENT_CACHE) - f2fs_fallocate - f2fs_insert_range - f2fs_drop_extent_tree - __drop_extent_tree - __may_extent_tree - test_opt(READ_EXTENT_CACHE) return true - write_lock(&et->lock) access NULL pointer - parse_options - clear_opt(READ_EXTENT_CACHE)

Published: 2025-09-18Modified: 2026-01-14
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53460
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix memory leak in rtw_usb_probe() drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe() warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811 Fix this by modifying return to a goto statement.

Published: 2025-10-01Modified: 2026-01-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53486
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Enhance the attribute size check This combines the overflow and boundary check so that all attribute size will be properly examined while enumerating them. [ 169.181521] BUG: KASAN: slab-out-of-bounds in run_unpack+0x2e3/0x570 [ 169.183161] Read of size 1 at addr ffff8880094b6240 by task mount/247 [ 169.184046] [ 169.184925] CPU: 0 PID: 247 Comm: mount Not tainted 6.0.0-rc7+ #3 [ 169.185908] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 169.187066] Call Trace: [ 169.187492] [ 169.188049] dump_stack_lvl+0x49/0x63 [ 169.188495] print_report.cold+0xf5/0x689 [ 169.188964] ? run_unpack+0x2e3/0x570 [ 169.189331] kasan_report+0xa7/0x130 [ 169.189714] ? run_unpack+0x2e3/0x570 [ 169.190079] __asan_load1+0x51/0x60 [ 169.190634] run_unpack+0x2e3/0x570 [ 169.191290] ? run_pack+0x840/0x840 [ 169.191569] ? run_lookup_entry+0xb3/0x1f0 [ 169.192443] ? mi_enum_attr+0x20a/0x230 [ 169.192886] run_unpack_ex+0xad/0x3e0 [ 169.193276] ? run_unpack+0x570/0x570 [ 169.193557] ? ni_load_mi+0x80/0x80 [ 169.193889] ? debug_smp_processor_id+0x17/0x20 [ 169.194236] ? mi_init+0x4a/0x70 [ 169.194496] attr_load_runs_vcn+0x166/0x1c0 [ 169.194851] ? attr_data_write_resident+0x250/0x250 [ 169.195188] mi_read+0x133/0x2c0 [ 169.195481] ntfs_iget5+0x277/0x1780 [ 169.196017] ? call_rcu+0x1c7/0x330 [ 169.196392] ? ntfs_get_block_bmap+0x70/0x70 [ 169.196708] ? evict+0x223/0x280 [ 169.197014] ? __kmalloc+0x33/0x540 [ 169.197305] ? wnd_init+0x15b/0x1b0 [ 169.197599] ntfs_fill_super+0x1026/0x1ba0 [ 169.197994] ? put_ntfs+0x1d0/0x1d0 [ 169.198299] ? vsprintf+0x20/0x20 [ 169.198583] ? mutex_unlock+0x81/0xd0 [ 169.198930] ? set_blocksize+0x95/0x150 [ 169.199269] get_tree_bdev+0x232/0x370 [ 169.199750] ? put_ntfs+0x1d0/0x1d0 [ 169.200094] ntfs_fs_get_tree+0x15/0x20 [ 169.200431] vfs_get_tree+0x4c/0x130 [ 169.200714] path_mount+0x654/0xfe0 [ 169.201067] ? putname+0x80/0xa0 [ 169.201358] ? finish_automount+0x2e0/0x2e0 [ 169.201965] ? putname+0x80/0xa0 [ 169.202445] ? kmem_cache_free+0x1c4/0x440 [ 169.203075] ? putname+0x80/0xa0 [ 169.203414] do_mount+0xd6/0xf0 [ 169.203719] ? path_mount+0xfe0/0xfe0 [ 169.203977] ? __kasan_check_write+0x14/0x20 [ 169.204382] __x64_sys_mount+0xca/0x110 [ 169.204711] do_syscall_64+0x3b/0x90 [ 169.205059] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 169.205571] RIP: 0033:0x7f67a80e948a [ 169.206327] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 169.208296] RSP: 002b:00007ffddf020f58 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5 [ 169.209253] RAX: ffffffffffffffda RBX: 000055e2547a6060 RCX: 00007f67a80e948a [ 169.209777] RDX: 000055e2547a6260 RSI: 000055e2547a62e0 RDI: 000055e2547aeaf0 [ 169.210342] RBP: 0000000000000000 R08: 000055e2547a6280 R09: 0000000000000020 [ 169.210843] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 000055e2547aeaf0 [ 169.211307] R13: 000055e2547a6260 R14: 0000000000000000 R15: 00000000ffffffff [ 169.211913] [ 169.212304] [ 169.212680] Allocated by task 0: [ 169.212963] (stack is not available) [ 169.213200] [ 169.213472] The buggy address belongs to the object at ffff8880094b5e00 [ 169.213472] which belongs to the cache UDP of size 1152 [ 169.214095] The buggy address is located 1088 bytes inside of [ 169.214095] 1152-byte region [ffff8880094b5e00, ffff8880094b6280) [ 169.214639] [ 169.215004] The buggy address belongs to the physical page: [ 169.215766] page:000000002e324c8c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x94b4 [ 169.218412] head:000000002e324c8c order:2 compound_mapcount:0 compound_pincount:0 [ 169.219078] flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) [ 169.220272] raw: 000fffffc0010200 ---truncated---

Published: 2025-10-01Modified: 2026-01-20
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2023-53491
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: start_kernel: Add __no_stack_protector function attribute Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it. Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.

Published: 2025-10-01Modified: 2026-01-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53510
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix handling of lrbp->cmd ufshcd_queuecommand() may be called two times in a row for a SCSI command before it is completed. Hence make the following changes: - In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths. - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd. See also scsi_send_eh_cmnd(). This commit prevents that the following appears if a command times out: WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8 Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0

Published: 2025-10-01Modified: 2026-04-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-53523
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: fix time stamp counter initialization If the gs_usb device driver is unloaded (or unbound) before the interface is shut down, the USB stack first calls the struct usb_driver::disconnect and then the struct net_device_ops::ndo_stop callback. In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more RX'ed CAN frames are send from the USB device to the host. Later in gs_can_close() a reset control message is send to each CAN channel to remove the controller from the CAN bus. In this race window the USB device can still receive CAN frames from the bus and internally queue them to be send to the host. At least in the current version of the candlelight firmware, the queue of received CAN frames is not emptied during the reset command. After loading (or binding) the gs_usb driver, new URBs are submitted during the struct net_device_ops::ndo_open callback and the candlelight firmware starts sending its already queued CAN frames to the host. However, this scenario was not considered when implementing the hardware timestamp function. The cycle counter/time counter infrastructure is set up (gs_usb_timestamp_init()) after the USBs are submitted, resulting in a NULL pointer dereference if timecounter_cyc2time() (via the call chain: gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() -> gs_usb_skb_set_timestamp()) is called too early. Move the gs_usb_timestamp_init() function before the URBs are submitted to fix this problem. For a comprehensive solution, we need to consider gs_usb devices with more than 1 channel. The cycle counter/time counter infrastructure is setup per channel, but the RX URBs are per device. Once gs_can_open() of _a_ channel has been called, and URBs have been submitted, the gs_usb_receive_bulk_callback() can be called for _all_ available channels, even for channels that are not running, yet. As cycle counter/time counter has not set up, this will again lead to a NULL pointer dereference. Convert the cycle counter/time counter from a "per channel" to a "per device" functionality. Also set it up, before submitting any URBs to the device. Further in gs_usb_receive_bulk_callback(), don't process any URBs for not started CAN channels, only resubmit the URB.

Published: 2025-10-01Modified: 2026-04-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53529
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: Fix memory leak in rtw88_usb Kmemleak shows the following leak arising from routine in the usb probe routine: unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [] kmalloc_trace+0x26/0x90 [] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [] usb_probe_interface+0xdd/0x2e0 [usbcore] [] really_probe+0x18e/0x3d0 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xbf/0x1b0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x10e/0x210 [] driver_register+0x55/0xf0 [] usb_register_driver+0x88/0x140 [usbcore] [] do_one_initcall+0x43/0x210 [] do_init_module+0x4a/0x200 [] __do_sys_finit_module+0xac/0x120 [] do_syscall_64+0x56/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The leak was verified to be real by unloading the driver, which resulted in a dangling pointer to the allocation. The allocated memory is freed in rtw_usb_intf_deinit().

Published: 2025-10-01Modified: 2026-01-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53538
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: insert tree mod log move in push_node_left There is a fairly unlikely race condition in tree mod log rewind that can result in a kernel panic which has the following trace: [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #PF: error_code(0x0000) - not-present page [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [530.928] Call Trace: [530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] ? btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve_indirect_ref+0xfe/0x6f0 [531.076] ? ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0 This occurs when logical inode resolution takes a tree mod log sequence number, and then while backref walking hits a rewind on a busy node which has the following sequence of tree mod log operations (numbers filled in from a specific example, but they are somewhat arbitrary) REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 When this sequence gets applied via btrfs_tree_mod_log_rewind, it allocates a fresh rewind eb, and first inserts the correct key info for the 533 elements, then overwrites the first 456 of them, then decrements the count by 456 via the add ops, then rewinds the move by doing a memmove from 456:988->0:532. We have never written anything past 532, ---truncated---

Published: 2025-10-04Modified: 2026-03-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53545
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: unmap and remove csa_va properly Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Published: 2025-10-04Modified: 2026-03-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53574
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: delete timer and free skb queue when unloading Fix possible crash and memory leak on driver unload by deleting TX purge timer and freeing C2H queue in 'rtw_core_deinit()', shrink critical section in the latter by freeing COEX queue out of TX report lock scope.

Published: 2025-10-04Modified: 2026-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-53627
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.list When freeing slots in function slot_complete_v3_hw(), it is possible that sas_dev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows: ==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task() ==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe() [ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32 [ 7165.434926] sas: trying to find task 0x00000000769b5ba5 [ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5 [ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored [ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored [ 7165.434976] Mem abort info: [ 7165.434982] ESR = 0x96000004 [ 7165.434991] Exception class = DABT (current EL), IL = 32 bits [ 7165.434992] SET = 0, FnV = 0 [ 7165.434993] EA = 0, S1PTW = 0 [ 7165.434994] Data abort info: [ 7165.434994] ISV = 0, ISS = 0x00000004 [ 7165.434995] CM = 0, WnR = 0 [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2 [ 7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP [ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5) [ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw] [ 7165.485247] sp : ffff00001d623bc0 [ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508 [ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8 [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8 [ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00 [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8 [ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff [ 7165.520276] x17: 0000000000000000 x16: 0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0 [ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00 [ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e [ 7165.567872] Call trace: [ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw] [ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main] [ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas] [ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas] [ 7165.592082] scsi_error_handler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] ret_from_fork+0x10/0x18 [ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021) [ 7165.609004] kernel fault(0x1) notification starting on CPU 75 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [ 7165.705326] Kernel panic - not syncing: Fatal exception To fix the issue, grab sas_dev lock when traversing the members of sas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoid concurrency of adding and deleting member. When ---truncated---

Published: 2025-10-07Modified: 2026-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-6039
MEDIUM5.5

A use-after-free flaw was found in lan78xx_disconnect in drivers/net/usb/lan78xx.c in the network sub-component, net/usb/lan78xx in the Linux Kernel. This flaw allows a local attacker to crash the system when the LAN78XX USB device detaches.

Published: 2023-11-09Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-6546
HIGH7.0

A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate their privileges on the system.

Published: 2023-12-21Modified: 2026-02-18
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2023-6560
MEDIUM5.5

An out-of-bounds memory access flaw was found in the io_uring SQ/CQ rings functionality in the Linux kernel. This issue could allow a local user to crash the system.

Published: 2023-12-09Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-6622
MEDIUM5.5

A null pointer dereference vulnerability was found in nft_dynset_init() in net/netfilter/nft_dynset.c in nf_tables in the Linux kernel. This issue may allow a local attacker with CAP_NET_ADMIN user privilege to trigger a denial of service.

Published: 2023-12-08Modified: 2025-06-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2023-7192
MEDIUM4.4

A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.

Published: 2024-01-02Modified: 2024-11-21
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-0340
MEDIUM5.5

A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.

Published: 2024-01-09Modified: 2025-05-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-0639
MEDIUM5.5

A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel’s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.

Published: 2024-01-17Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-0641
MEDIUM5.5

A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel’s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.

Published: 2024-01-17Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-0775
HIGH7.1

A use-after-free flaw was found in the __ext4_remount in fs/ext4/super.c in ext4 in the Linux kernel. This flaw allows a local user to cause an information leak problem while freeing the old quota file names before a potential failure, leading to a use-after-free.

Published: 2024-01-22Modified: 2024-11-21
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-0841
HIGH7.8

A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.

Published: 2024-01-28Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-1312
MEDIUM4.7

A use-after-free flaw was found in the Linux kernel's Memory Management subsystem when a user wins two races at the same time with a fail in the mas_prev_slot function. This issue could allow a local user to crash the system.

Published: 2024-02-08Modified: 2024-11-21
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-21803
HIGH7.8

Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows Local Execution of Code. This vulnerability is associated with program files https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C. This issue affects Linux kernel: from v2.6.12-rc2 before v6.8-rc1.

Published: 2024-01-30Modified: 2025-08-15
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-22705
HIGH7.8

An issue was discovered in ksmbd in the Linux kernel before 6.6.10. smb2_get_data_area_len in fs/smb/server/smb2misc.c can cause an smb_strndup_from_utf16 out-of-bounds access because the relationship between Name data and CreateContexts data is mishandled.

Published: 2024-01-23Modified: 2025-06-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-24855
MEDIUM4.7

A race condition was found in the Linux kernel's scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

Published: 2024-02-05Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-24857
MEDIUM6.8

A race condition was found in the Linux kernel's net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.

Published: 2024-02-05Modified: 2025-03-05
CVSS 3.xMEDIUM 6.8
CVSS:3.x/CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-24858
MEDIUM5.3

A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.

Published: 2024-02-05Modified: 2025-03-05
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-25744
HIGH8.8

In the Linux kernel before 6.6.7, an untrusted VMM can trigger int80 syscall handling at any given point. This is related to arch/x86/coco/tdx/tdx.c and arch/x86/mm/mem_encrypt_amd.c.

Published: 2024-02-12Modified: 2025-05-07
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
References
CVE-2024-26581
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: skip end interval element from gc rbtree lazy gc on insert might collect an end interval element that has been just added in this transactions, skip end interval elements that are not yet active.

Published: 2024-02-20Modified: 2025-10-01
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26582
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: tls: fix use-after-free with partial reads and async decrypt tls_decrypt_sg doesn't take a reference on the pages from clear_skb, so the put_page() in tls_decrypt_done releases them, and we trigger a use-after-free in process_rx_list when we try to read from the partially-read skb.

Published: 2024-02-21Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26583
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires.

Published: 2024-02-21Modified: 2025-11-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26584
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical.

Published: 2024-02-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26585
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do.

Published: 2024-02-21Modified: 2025-11-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26586
MEDIUM6.7

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Published: 2024-02-22Modified: 2024-11-21
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26587
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: netdevsim: don't try to destroy PHC on VFs PHC gets initialized in nsim_init_netdevsim(), which is only called if (nsim_dev_port_is_pf()). Create a counterpart of nsim_init_netdevsim() and move the mock_phc_destroy() there. This fixes a crash trying to destroy netdevsim with VFs instantiated, as caught by running the devlink.sh test: BUG: kernel NULL pointer dereference, address: 00000000000000b8 RIP: 0010:mock_phc_destroy+0xd/0x30 Call Trace: nsim_destroy+0x4a/0x70 [netdevsim] __nsim_dev_port_del+0x47/0x70 [netdevsim] nsim_dev_reload_destroy+0x105/0x120 [netdevsim] nsim_drv_remove+0x2f/0xb0 [netdevsim] device_release_driver_internal+0x1a1/0x210 bus_remove_device+0xd5/0x120 device_del+0x159/0x490 device_unregister+0x12/0x30 del_device_store+0x11a/0x1a0 [netdevsim] kernfs_fop_write_iter+0x130/0x1d0 vfs_write+0x30b/0x4b0 ksys_write+0x69/0xf0 do_syscall_64+0xcc/0x1e0 entry_SYSCALL_64_after_hwframe+0x6f/0x77

Published: 2024-02-22Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26590
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: erofs: fix inconsistent per-file compression format EROFS can select compression algorithms on a per-file basis, and each per-file compression algorithm needs to be marked in the on-disk superblock for initialization. However, syzkaller can generate inconsistent crafted images that use an unsupported algorithmtype for specific inodes, e.g. use MicroLZMA algorithmtype even it's not set in `sbi->available_compr_algs`. This can lead to an unexpected "BUG: kernel NULL pointer dereference" if the corresponding decompressor isn't built-in. Fix this by checking against `sbi->available_compr_algs` for each m_algorithmformat request. Incorrect !erofs_sb_has_compr_cfgs preset bitmap is now fixed together since it was harmless previously.

Published: 2024-02-22Modified: 2025-04-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26593
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call transactions According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read.

Published: 2024-02-23Modified: 2025-11-04
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-26595
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Published: 2024-02-23Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26600
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example: configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 Let's fix the issue by checking for send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL.

Published: 2024-02-26Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26601
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case.

Published: 2024-02-26Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26602
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.

Published: 2024-02-26Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26603
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak subject / changelog ]

Published: 2024-02-26Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26606
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self-work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work.

Published: 2024-02-26Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26621
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: don't force huge page alignment on 32 bit commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") caused two issues [1] [2] reported on 32 bit system or compat userspace. It doesn't make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/

Published: 2024-03-02Modified: 2025-01-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26622
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems.

Published: 2024-03-04Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26629
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). It is not clear what the other one is expected to be. In practice, the count is often 2 because there is precisely one state on so_stateids. If there were more, this would fail. In my testing I see two circumstances when RELEASE_LOCKOWNER is called. In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in all the lock states being removed, and so the lockowner being discarded (it is removed when there are no more references which usually happens when the lock state is discarded). When nfsd4_release_lockowner() finds that the lock owner doesn't exist, it returns success. The other case shows an so_count of '2' and precisely one state listed in so_stateid. It appears that the Linux client uses a separate lock owner for each file resulting in one lock state per lock owner, so this test on '2' is safe. For another client it might not be safe. So this patch changes check_for_locks() to use the (newish) find_any_file_locked() so that it doesn't take a reference on the nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With this check is it safe to restore the use of check_for_locks() rather than testing so_count against the mysterious '2'.

Published: 2024-03-13Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26642
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this. Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.

Published: 2024-03-21Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26643
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.

Published: 2024-03-21Modified: 2025-03-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26647
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix late derefrence 'dsc' check in 'link_set_dsc_pps_packet()' In link_set_dsc_pps_packet(), 'struct display_stream_compressor *dsc' was dereferenced in a DC_LOGGER_INIT(dsc->ctx->logger); before the 'dsc' NULL pointer check. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:905 link_set_dsc_pps_packet() warn: variable dereferenced before check 'dsc' (see line 903)

Published: 2024-03-26Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26648
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix variable deferencing before NULL check in edp_setup_replay() In edp_setup_replay(), 'struct dc *dc' & 'struct dmub_replay *replay' was dereferenced before the pointer 'link' & 'replay' NULL check. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:947 edp_setup_replay() warn: variable dereferenced before check 'link' (see line 933)

Published: 2024-03-26Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26651
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sr9800: Add check for usbnet_get_endpoints Add check for usbnet_get_endpoints() and return the error if it fails in order to transfer the error.

Published: 2024-03-27Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26654
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard->timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below: (Thread 1) | (Thread 2) snd_aicapcm_pcm_close() | ... | run_spu_dma() //worker | mod_timer() flush_work() | del_timer() | aica_period_elapsed() //timer kfree(dreamcastcard->channel) | schedule_work() | run_spu_dma() //worker ... | dreamcastcard->channel-> //USE In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed.

Published: 2024-04-01Modified: 2025-02-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26659
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26660
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN301 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn301_stream_encoder_create reported by Smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5

Published: 2024-04-02Modified: 2025-03-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26661
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()' In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;" pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to ensure the tg is not NULL.

Published: 2024-04-02Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26662
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()' 'panel_cntl' structure used to control the display panel could be null, dereferencing it could lead to a null pointer access. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)

Published: 2024-04-02Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26663
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().

Published: 2024-04-02Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26664
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Fix out-of-bounds memory access Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-26665
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: tunnels: fix out of bounds access when building IPv6 PMTU error If the ICMPv6 error is built from a non-linear skb we get the following splat, BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 Use skb_checksum instead of csum_partial who cannot deal with non-linear SKBs.

Published: 2024-04-02Modified: 2025-03-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-26667
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanup The commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writeback in case of YUV output") introduced a smatch warning about another conditional block in dpu_encoder_helper_phys_cleanup() which had assumed hw_pp will always be valid which may not necessarily be true. Lets fix the other conditional block by making sure hw_pp is valid before dereferencing it. Patchwork: https://patchwork.freedesktop.org/patch/574878/

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26669
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: net/sched: flower: Fix chain template offload When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter. However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2]. Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one. As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains. [1] unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc+0x4e/0x90 [] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [] ___sys_sendmsg+0x13a/0x1e0 [] __sys_sendmsg+0x11c/0x1f0 [] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m.... backtrace: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc_node+0x51/0x90 [] kvmalloc_node+0xa6/0x1f0 [] bucket_table_alloc.isra.0+0x83/0x460 [] rhashtable_init+0x43b/0x7c0 [] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev ---truncated---

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-26675
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K") Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26676
MEDIUM5.5

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: process_one_work+0x889/0x15e0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x12a0 kernel/workqueue.c:2787 kthread+0x2c6/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242

Published: 2024-04-02Modified: 2025-05-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26677
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26679
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning.

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26680
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26681
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netdevsim: avoid potential loop in nsim_dev_trap_report_work() Many syzbot reports include the following trace [1] If nsim_dev_trap_report_work() can not grab the mutex, it should rearm itself at least one jiffie later. [1] Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189 Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00 RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046 RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3 RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0 RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1e R10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002 R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: instrument_atomic_read include/linux/instrumented.h:68 [inline] atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline] queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline] debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline] do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline] _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194 debug_object_activate+0x349/0x540 lib/debugobjects.c:726 debug_work_activate kernel/workqueue.c:578 [inline] insert_work+0x30/0x230 kernel/workqueue.c:1650 __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802 __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953 queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989 queue_delayed_work include/linux/workqueue.h:563 [inline] schedule_delayed_work include/linux/workqueue.h:677 [inline] nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842 process_one_work+0x886/0x15d0 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26684
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.

Published: 2024-04-02Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26685
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential bug in end_buffer_async_write According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash. This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel. The use of async_write for segment summary buffers has already been removed in a previous change. Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer.

Published: 2024-04-03Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26687
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated---

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26688
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfs_fill_super() caused by assigning NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize is non valid. E.g: Taking the following steps: fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC); fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0); fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0); Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced with NULL, losing its previous value, and we will print an error: ... ... case Opt_pagesize: ps = memparse(param->string, &rest); ctx->hstate = h; if (!ctx->hstate) { pr_err("Unsupported page size %lu MB\n", ps / SZ_1M); return -EINVAL; } return 0; ... ... This is a problem because later on, we will dereference ctxt->hstate in hugetlbfs_fill_super() ... ... sb->s_blocksize = huge_page_size(ctx->hstate); ... ... Causing below Oops. Fix this by replacing cxt->hstate value only when then pagesize is known to be valid. kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel: kernel: ? __die_body+0x1a/0x60 kernel: ? page_fault_oops+0x16f/0x4a0 kernel: ? search_bpf_extables+0x65/0x70 kernel: ? fixup_exception+0x22/0x310 kernel: ? exc_page_fault+0x69/0x150 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: ? hugetlbfs_fill_super+0xb4/0x1a0 kernel: ? hugetlbfs_fill_super+0x28/0x1a0 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: vfs_get_super+0x40/0xa0 kernel: ? __pfx_bpf_lsm_capable+0x10/0x10 kernel: vfs_get_tree+0x25/0xd0 kernel: vfs_cmd_create+0x64/0xe0 kernel: __x64_sys_fsconfig+0x395/0x410 kernel: do_syscall_64+0x80/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? exc_page_fault+0x69/0x150 kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX: fffffffffff ---truncated---

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26689
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed. In same file, in "handle_cap_grant()" refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error.

Published: 2024-04-03Modified: 2025-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26691
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix circular locking dependency The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data.

Published: 2024-04-03Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26695
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked The SEV platform device can be shutdown with a null psp_master, e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN: [ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598] ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] [ 137.182693] ? show_regs+0x6c/0x80 [ 137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? exc_general_protection+0x126/0x230 [ 137.182693] ? asm_exc_general_protection+0x2b/0x30 [ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80 [ 137.182693] sev_dev_destroy+0x49/0x100 [ 137.182693] psp_dev_destroy+0x47/0xb0 [ 137.182693] sp_destroy+0xbb/0x240 [ 137.182693] sp_pci_remove+0x45/0x60 [ 137.182693] pci_device_remove+0xaa/0x1d0 [ 137.182693] device_remove+0xc7/0x170 [ 137.182693] really_probe+0x374/0xbe0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] __driver_probe_device+0x199/0x460 [ 137.182693] driver_probe_device+0x4e/0xd0 [ 137.182693] __driver_attach+0x191/0x3d0 [ 137.182693] ? __pfx___driver_attach+0x10/0x10 [ 137.182693] bus_for_each_dev+0x100/0x190 [ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10 [ 137.182693] ? __kasan_check_read+0x15/0x20 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? _raw_spin_unlock+0x27/0x50 [ 137.182693] driver_attach+0x41/0x60 [ 137.182693] bus_add_driver+0x2a8/0x580 [ 137.182693] driver_register+0x141/0x480 [ 137.182693] __pci_register_driver+0x1d6/0x2a0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] sp_pci_init+0x22/0x30 [ 137.182693] sp_mod_init+0x14/0x30 [ 137.182693] ? __pfx_sp_mod_init+0x10/0x10 [ 137.182693] do_one_initcall+0xd1/0x470 [ 137.182693] ? __pfx_do_one_initcall+0x10/0x10 [ 137.182693] ? parameq+0x80/0xf0 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] ? __kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernel_init_freeable+0x92d/0x1050 [ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190 [ 137.182693] ? srso_return_thunk+0x5/0x5f [ 137.182693] kernel_init_freeable+0xa64/0x1050 [ 137.182693] ? __pfx_kernel_init+0x10/0x10 [ 137.182693] kernel_init+0x24/0x160 [ 137.182693] ? __switch_to_asm+0x3e/0x70 [ 137.182693] ret_from_fork+0x40/0x80 [ 137.182693] ? __pfx_kernel_init+0x1 ---truncated---

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26696
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26697
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26698
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel"), napi_disable was getting called for all channels, including all subchannels without confirming if they are enabled or not. This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() has finished running but nvdev->subchan_work has not started yet. netvsc_subchan_work() -> rndis_set_subchannel() has not created the sub-channels and because of that netvsc_sc_open() is not running. netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which netvsc_subchan_work did not run. netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the opposite. Now during netvsc_device_remove(), when napi_disable is called for those subchannels, napi_disable gets stuck on infinite msleep. This fix addresses this problem by ensuring that napi_disable() is not getting called for non-enabled NAPI struct. But netif_napi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose. Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] Call Trace: [ 654.571221] [ 654.573790] __schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] schedule_timeout+0x87/0x140 [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [ 654.611101] ? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26700
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix MST Null Ptr for RV The change try to fix below error specific to RV platform: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 ? _copy_to_user+0x25/0x30 ? drm_ioctl+0x296/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xcd/0x170 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4dad17f76f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0 Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep > typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas> CR2: 0000000000000008 ---[ end trace 0000000000000000 ]--- RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000 ---truncated---

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26702
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC Recently, we encounter kernel crash in function rm3100_common_probe caused by out of bound access of array rm3100_samp_rates (because of underlying hardware failures). Add boundary check to prevent out of bound access.

Published: 2024-04-03Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26704
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue.

Published: 2024-04-03Modified: 2025-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26706
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer. This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register. Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT config option any longer.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26707
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() Syzkaller reported [1] hitting a warning after failing to allocate resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will not help much in this case, it might be prudent to switch to netdev_warn_once(). At the very least it will suppress syzkaller reports such as [1]. Just in case, use netdev_warn_once() in send_prp_supervision_frame() for similar reasons. [1] HSR: Could not send supervision frame WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 ... Call Trace: hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ... This issue is also found in older kernels (at least up to 5.10).

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26710
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Limit KASAN thread size increase to 32KB KASAN is seen to increase stack usage, to the point that it was reported to lead to stack overflow on some 32-bit machines (see link). To avoid overflows the stack size was doubled for KASAN builds in commit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase with KASAN"). However with a 32KB stack size to begin with, the doubling leads to a 64KB stack, which causes build errors: arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff) Although the asm could be reworked, in practice a 32KB stack seems sufficient even for KASAN builds - the additional usage seems to be in the 2-3KB range for a 64-bit KASAN build. So only increase the stack for KASAN if the stack size is < 32KB.

Published: 2024-04-03Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26712
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address.

Published: 2024-04-03Modified: 2025-04-08
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26714
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: interconnect: qcom: sc8180x: Mark CO0 BCM keepalive The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam. Mark it as keepalive to prevent such cases.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26715
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur.

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26717
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid-of: fix NULL-deref on failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures.

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26718
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dm-crypt, dm-verity: disable tasklets Tasklets have an inherent problem with memory corruption. The function tasklet_action_common calls tasklet_trylock, then it calls the tasklet callback and then it calls tasklet_unlock. If the tasklet callback frees the structure that contains the tasklet or if it calls some code that may free it, tasklet_unlock will write into free memory. The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but it is not a sufficient fix and the data corruption can still happen [1]. There is no fix for dm-verity and dm-verity will write into free memory with every tasklet-processed bio. There will be atomic workqueues implemented in the kernel 6.9 [2]. They will have better interface and they will not suffer from the memory corruption problem. But we need something that stops the memory corruption now and that can be backported to the stable kernels. So, I'm proposing this commit that disables tasklets in both dm-crypt and dm-verity. This commit doesn't remove the tasklet support, because the tasklet code will be reused when atomic workqueues will be implemented. [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/ [2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26719
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue.

Published: 2024-04-03Modified: 2025-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26722
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work() There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutex is left locked forever. That may lead to deadlock when rt5645_jack_detect_work() is called for the second time. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26723
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: lan966x: Fix crash when adding interface under a lag There is a crash when adding one of the lan966x interfaces under a lag interface. The issue can be reproduced like this: ip link add name bond0 type bond miimon 100 mode balance-xor ip link set dev eth0 master bond0 The reason is because when adding a interface under the lag it would go through all the ports and try to figure out which other ports are under that lag interface. And the issue is that lan966x can have ports that are NULL pointer as they are not probed. So then iterating over these ports it would just crash as they are NULL pointers. The fix consists in actually checking for NULL pointers before accessing something from the ports. Like we do in other places.

Published: 2024-04-03Modified: 2025-04-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26726
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map. Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test.

Published: 2024-04-03Modified: 2025-07-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26727
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not ASSERT() if the newly created subvolume already got read [BUG] There is a syzbot crash, triggered by the ASSERT() during subvolume creation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CAUSE] During create_subvol(), after inserting root item for the newly created subvolume, we would trigger btrfs_get_new_fs_root() to get the btrfs_root of that subvolume. The idea here is, we have preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume. But there is really nothing preventing things like backref walk to read the new subvolume. If that happens before we call btrfs_get_new_fs_root(), the subvolume would be read out, with a new anonymous device number assigned already. In that case, we would trigger ASSERT(), as we really expect no one to read out that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible to trigger the read on the subvolume. Thus our assumption on the ASSERT() is not correct in the first place. [FIX] Fix it by removing the ASSERT(), and just free the @anon_dev, reset it to 0, and continue. If the subvolume tree is read out by something else, it should have already get a new anon_dev assigned thus we only need to free the preallocated one.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26731
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready() syzbot reported the following NULL pointer dereference issue [1]: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:0x0 [...] Call Trace: sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230 unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are called concurrently, psock->saved_data_ready can be NULL, causing the above issue. This patch fixes this issue by calling the appropriate data ready function using the sk_psock_data_ready() helper and protecting it from concurrency with sk->sk_callback_lock.

Published: 2024-04-03Modified: 2025-04-03
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-26733
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller. [0]: memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26735
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix possible use-after-free and null-ptr-deref The pernet operations structure for the subsystem must be registered before registering the generic netlink family.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26736
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: afs: Increase buffer size in afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26737
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period.

Published: 2024-04-03Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26739
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: don't override retval if we already lost the skb If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it.

Published: 2024-04-03Modified: 2025-11-25
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26740
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26741
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dccp/tcp: Unhash sk from ehash for tb2 alloc failure after check_estalblished(). syzkaller reported a warning [0] in inet_csk_destroy_sock() with no repro. WARN_ON(inet_sk(sk)->inet_num && !inet_csk(sk)->icsk_bind_hash); However, the syzkaller's log hinted that connect() failed just before the warning due to FAULT_INJECTION. [1] When connect() is called for an unbound socket, we search for an available ephemeral port. If a bhash bucket exists for the port, we call __inet_check_established() or __inet6_check_established() to check if the bucket is reusable. If reusable, we add the socket into ehash and set inet_sk(sk)->inet_num. Later, we look up the corresponding bhash2 bucket and try to allocate it if it does not exist. Although it rarely occurs in real use, if the allocation fails, we must revert the changes by check_established(). Otherwise, an unconnected socket could illegally occupy an ehash entry. Note that we do not put tw back into ehash because sk might have already responded to a packet for tw and it would be better to free tw earlier under such memory presure. [0]: WARNING: CPU: 0 PID: 350830 at net/ipv4/inet_connection_sock.c:1193 inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Modules linked in: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) Code: 41 5c 41 5d 41 5e e9 2d 4a 3d fd e8 28 4a 3d fd 48 89 ef e8 f0 cd 7d ff 5b 5d 41 5c 41 5d 41 5e e9 13 4a 3d fd e8 0e 4a 3d fd <0f> 0b e9 61 fe ff ff e8 02 4a 3d fd 4c 89 e7 be 03 00 00 00 e8 05 RSP: 0018:ffffc9000b21fd38 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000009e78 RCX: ffffffff840bae40 RDX: ffff88806e46c600 RSI: ffffffff840bb012 RDI: ffff88811755cca8 RBP: ffff88811755c880 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000009e78 R11: 0000000000000000 R12: ffff88811755c8e0 R13: ffff88811755c892 R14: ffff88811755c918 R15: 0000000000000000 FS: 00007f03e5243800(0000) GS:ffff88811ae00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32f21000 CR3: 0000000112ffe001 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: ? inet_csk_destroy_sock (net/ipv4/inet_connection_sock.c:1193) dccp_close (net/dccp/proto.c:1078) inet_release (net/ipv4/af_inet.c:434) __sock_release (net/socket.c:660) sock_close (net/socket.c:1423) __fput (fs/file_table.c:377) __fput_sync (fs/file_table.c:462) __x64_sys_close (fs/open.c:1557 fs/open.c:1539 fs/open.c:1539) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7f03e53852bb Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 43 c9 f5 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 c9 f5 ff 8b 44 RSP: 002b:00000000005dfba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f03e53852bb RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000167c R10: 0000000008a79680 R11: 0000000000000293 R12: 00007f03e4e43000 R13: 00007f03e4e43170 R14: 00007f03e4e43178 R15: 00007f03e4e43170 [1]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 0 PID: 350833 Comm: syz-executor.1 Not tainted 6.7.0-12272-g2121c43f88f5 #9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3748) kmem_cache_alloc (mm/slub.c:3763 mm/slub.c:3842 mm/slub.c:3867) inet_bind2_bucket_create ---truncated---

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26742
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: scsi: smartpqi: Fix disable_managed_interrupts Correct blk-mq registration issue with module parameter disable_managed_interrupts enabled. When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to register with blk-mq using blk_mq_map_queues(). The driver is currently calling blk_mq_pci_map_queues() which results in a stack trace and possibly undefined behavior. Stack Trace: [ 7.860089] scsi host2: smartpqi [ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0 [ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1 [ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022 [ 7.963026] Workqueue: events work_for_cpu_fn [ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0 [ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54 [ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216 [ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010 [ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310 [ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00 [ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000 [ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8 [ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000 [ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0 [ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8.172818] PKRU: 55555554 [ 8.172819] Call Trace: [ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310 [ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245 [ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi] [ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi] [ 8.323286] local_pci_probe+0x42/0x80 [ 8.337855] work_for_cpu_fn+0x16/0x20 [ 8.351193] process_one_work+0x1a7/0x360 [ 8.364462] ? create_worker+0x1a0/0x1a0 [ 8.379252] worker_thread+0x1ce/0x390 [ 8.392623] ? create_worker+0x1a0/0x1a0 [ 8.406295] kthread+0x10a/0x120 [ 8.418428] ? set_kthread_struct+0x50/0x50 [ 8.431532] ret_from_fork+0x1f/0x40 [ 8.444137] ---[ end trace 1bf0173d39354506 ]---

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26743
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix qedr_create_user_qp error flow Avoid the following warning by making sure to free the allocated resources in case that qedr_init_user_queue() fail. -----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __warn+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x87c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 ? common_interrupt+0x43/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 --[ end trace 888a9b92e04c5c97 ]--

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26744
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Support specifying the srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76

Published: 2024-04-03Modified: 2025-05-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26745
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP _find_next_zero_bit+0x24/0x110 LR bitmap_find_next_zero_area_off+0x5c/0xe0 Call Trace: dev_printk_emit+0x38/0x48 (unreliable) iommu_area_alloc+0xc4/0x180 iommu_range_alloc+0x1e8/0x580 iommu_alloc+0x60/0x130 iommu_alloc_coherent+0x158/0x2b0 dma_iommu_alloc_coherent+0x3c/0x50 dma_alloc_attrs+0x170/0x1f0 mlx5_cmd_init+0xc0/0x760 [mlx5_core] mlx5_function_setup+0xf0/0x510 [mlx5_core] mlx5_init_one+0x84/0x210 [mlx5_core] probe_one+0x118/0x2c0 [mlx5_core] local_pci_probe+0x68/0x110 pci_call_probe+0x68/0x200 pci_device_probe+0xbc/0x1a0 really_probe+0x104/0x540 __driver_probe_device+0xb4/0x230 driver_probe_device+0x54/0x130 __driver_attach+0x158/0x2b0 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x16c/0x300 driver_register+0xa4/0x1b0 __pci_register_driver+0x68/0x80 mlx5_init+0xb8/0x100 [mlx5_core] do_one_initcall+0x60/0x300 do_init_module+0x7c/0x2b0 At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window "ibm,dma-window" is removed from the FDT and DDW added, for the device. Now, kexec hands over control to the kdump kernel. When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables. iommu_table_setparms_lpar() only considers "ibm,dma-window" property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs for the SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc(). The fix is to initialize the IOMMU table with DDW property stored in the FDT. There are 2 points to remember: 1. For the dedicated adapter, kdump kernel would encounter both default and DDW in FDT. In this case, DDW property is used to initialize the IOMMU table. 2. A DDW could be direct or dynamic mapped. kdump kernel would initialize IOMMU table and mark the existing DDW as "dynamic". This works fine since, at the time of table initialization, iommu_table_clear() makes some space in the DDW, for some predefined number of TCEs which are needed for kdump to succeed.

Published: 2024-04-04Modified: 2025-04-04
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26747
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue when put module's reference In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations.

Published: 2024-04-03Modified: 2025-04-04
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26748
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix memory double free when handle zero packet 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request); Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again. Log: [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver.

Published: 2024-04-03Modified: 2025-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26749
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ... 'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem.

Published: 2024-04-03Modified: 2025-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26751
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ARM: ep93xx: Add terminator to gpiod_lookup_table Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26752
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26753
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: crypto: virtio/akcipher - Fix stack overflow on memcpy sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o

Published: 2024-04-03Modified: 2025-02-27
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26754
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp() The gtp_net_ops pernet operations structure for the subsystem must be registered before registering the generic netlink family. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0

Published: 2024-04-03Modified: 2025-01-07
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26759
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix race when skipping swapcache When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads swapin the same entry at the same time, they get different pages (A, B). Before one thread (T0) finishes the swapin and installs page (A) to the PTE, another thread (T1) could finish swapin of page (B), swap_free the entry, then swap out the possibly modified page reusing the same entry. It breaks the pte_same check in (T0) because PTE value is unchanged, causing ABA problem. Thread (T0) will install a stalled page (A) into the PTE and cause data corruption. One possible callstack is like this: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() with same entry swap_read_folio() <- read to page A swap_read_folio() <- read to page B ... set_pte_at() swap_free() <- entry is free pte_same() <- Check pass, PTE seems unchanged, but page A is stalled! swap_free() <- page B content lost! set_pte_at() <- staled page A installed! And besides, for ZRAM, swap_free() allows the swap device to discard the entry content, so even if page (B) is not modified, if swap_read_folio() on CPU0 happens later than swap_free() on CPU1, it may also cause data loss. To fix this, reuse swapcache_prepare which will pin the swap entry using the cache flag, and allow only one thread to swap it in, also prevent any parallel code from putting the entry in the cache. Release the pin after PT unlocked. Racers just loop and wait since it's a rare and very short event. A schedule_timeout_uninterruptible(1) call is added to avoid repeated page faults wasting too much CPU, causing livelock or adding too much noise to perf statistics. A similar livelock issue was described in commit 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") Reproducer: This race issue can be triggered easily using a well constructed reproducer and patched brd (with a delay in read path) [1]: With latest 6.8 mainline, race caused data loss can be observed easily: $ gcc -g -lpthread test-thread-swap-race.c && ./a.out Polulating 32MB of memory region... Keep swapping out... Starting round 0... Spawning 65536 workers... 32746 workers spawned, wait for done... Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss! Round 0 Failed, 15 data loss! This reproducer spawns multiple threads sharing the same memory region using a small swap device. Every two threads updates mapped pages one by one in opposite direction trying to create a race, with one dedicated thread keep swapping out the data out using madvise. The reproducer created a reproduce rate of about once every 5 minutes, so the race should be totally possible in production. After this patch, I ran the reproducer for over a few hundred rounds and no data loss observed. Performance overhead is minimal, microbenchmark swapin 10G from 32G zram: Before: 10934698 us After: 11157121 us Cached: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag) [kasong@tencent.com: v4]

Published: 2024-04-03Modified: 2025-04-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26760
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: target: pscsi: Fix bio_put() for error case As of commit 066ff571011d ("block: turn bio_kmalloc into a simple kmalloc wrapper"), a bio allocated by bio_kmalloc() must be freed by bio_uninit() and kfree(). That is not done properly for the error case, hitting WARN and NULL pointer dereference in bio_free().

Published: 2024-04-03Modified: 2025-03-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26761
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cxl/pci: Fix disabling memory if DVSEC CXL Range does not match a CFMWS window The Linux CXL subsystem is built on the assumption that HPA == SPA. That is, the host physical address (HPA) the HDM decoder registers are programmed with are system physical addresses (SPA). During HDM decoder setup, the DVSEC CXL range registers (cxl-3.1, 8.1.3.8) are checked if the memory is enabled and the CXL range is in a HPA window that is described in a CFMWS structure of the CXL host bridge (cxl-3.1, 9.18.1.3). Now, if the HPA is not an SPA, the CXL range does not match a CFMWS window and the CXL memory range will be disabled then. The HDM decoder stops working which causes system memory being disabled and further a system hang during HDM decoder initialization, typically when a CXL enabled kernel boots. Prevent a system hang and do not disable the HDM decoder if the decoder's CXL range is not found in a CFMWS window. Note the change only fixes a hardware hang, but does not implement HPA/SPA translation. Support for this can be added in a follow on patch series.

Published: 2024-04-03Modified: 2025-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26763
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/

Published: 2024-04-03Modified: 2025-03-18
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-26764
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio.

Published: 2024-04-03Modified: 2025-03-18
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-26765
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Disable IRQ before init_fn() for nonboot CPUs Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to silence such warnings (and also avoid potential errors due to unexpected interrupts): WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000 t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0 -PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 0000000000000004 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 0000000000000000 0000000000000000 0000000000071000 ... Call Trace: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init+0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [<9000000005b66134>] smpboot_entry+0x50/0x58

Published: 2024-04-03Modified: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26766
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix sdma.h tx->num_descs off-by-one error Unfortunately the commit `fd8958efe877` introduced another error causing the `descs` array to overflow. This reults in further crashes easily reproducible by `sendmsg` system call. [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535] Call Trace: [ 1080.976990] [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1] [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978] dev_hard_start_xmit+0xc4/0x210 -- [ 1081.148347] __sys_sendmsg+0x59/0xa0 crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = { list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 , packet_len = 0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, flags = 0x0, descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = { 0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = { 0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 } If an SDMA send consists of exactly 6 descriptors and requires dword padding (in the 7th descriptor), the sdma_txreq descriptor array is not properly expanded and the packet will overflow into the container structure. This results in a panic when the send completion runs. The exact panic varies depending on what elements of the container structure get corrupted. The fix is to use the correct expression in _pad_sdma_tx_descs() to test the need to expand the descriptor array. With this patch the crashes are no longer reproducible and the machine is stable.

Published: 2024-04-03Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26767
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fixed integer types and null check locations [why]: issues fixed: - comparison with wider integer type in loop condition which can cause infinite loops - pointer dereference before null check

Published: 2024-04-03Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26768
MEDIUM6.5

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With default config, the value of NR_CPUS is 64. When HW platform has more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC is the maximum cpu number in MADT table (max physical number) which can exceed the supported maximum cpu number (NR_CPUS, max logical number), but kernel should not crash. Kernel should boot cpus with NR_CPUS, let the remainder cpus stay in BIOS. The potential crash reason is that the array acpi_core_pic[NR_CPUS] can be overflowed when parsing MADT table, and it is obvious that CORE_PIC should be corresponding to physical core rather than logical core, so it is better to define the array as acpi_core_pic[MAX_CORE_PIC]. With the patch, system can boot up 64 vcpus with qemu parameter -smp 128, otherwise system will crash with the following message. [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192 [ 0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60 [ 0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8 [ 0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005 [ 0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001 [ 0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063 [ 0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98 [ 0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90 [ 0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330 [ 0.000000] ra: 90000000037a46ec platform_init+0x214/0x250 [ 0.000000] ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94 [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 0.000000] BADV: 0000420000004259 [ 0.000000] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec [ 0.000000] 000000000a7fd000 0000000008290000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 00000000019d8000 000000000f556b60 [ 0.000000] 000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000 [ 0.000000] 9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c [ 0.000000] 000000000e0a4330 000000000f556b60 000000000a7fd000 000000000f556b08 [ 0.000000] 9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018 [ 0.000000] 000000000a7fd000 90000000037a0790 9000000003800108 0000000000000000 [ 0.000000] 0000000000000000 000000000e0a4330 000000000f556b60 000000000a7fd000 [ 0.000000] 000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<90000000037a5f0c>] efi_runtime_init+0x30/0x94 [ 0.000000] [<90000000037a46ec>] platform_init+0x214/0x250 [ 0.000000] [<90000000037a484c>] setup_arch+0x124/0x45c [ 0.000000] [<90000000037a0790>] start_kernel+0x90/0x670 [ 0.000000] [<900000000378b0d8>] kernel_entry+0xd8/0xdc

Published: 2024-04-03Modified: 2025-04-04
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
References
CVE-2024-26769
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid deadlock on delete association path When deleting an association the shutdown path is deadlocking because we try to flush the nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item.

Published: 2024-04-03Modified: 2025-04-04
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26770
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: HID: nvidia-shield: Add missing null pointer checks to LED initialization devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. [jkosina@suse.com: tweak changelog a bit]

Published: 2024-04-03Modified: 2025-01-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26771
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Add some null pointer checks to the edma_probe devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.

Published: 2024-04-03Modified: 2025-01-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26772
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap.

Published: 2024-04-03Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26773
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group

Published: 2024-04-03Modified: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26774
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Determine if bb_fragments is 0 instead of determining bb_free to eliminate the risk of dividing by zero when the block bitmap is corrupted.

Published: 2024-04-03Modified: 2025-06-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26775
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: aoe: avoid potential deadlock at set_capacity Move set_capacity() outside of the section procected by (&d->lock). To avoid possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- [1] lock(&bdev->bd_size_lock); local_irq_disable(); [2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); [4] lock(&d->lock); *** DEADLOCK *** Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity(). [2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc() is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call. In this situation an attempt to acquire [4]lock(&d->lock) from aoecmd_cfg_rsp() will lead to deadlock. So the simplest solution is breaking lock dependency [2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity() outside.

Published: 2024-04-03Modified: 2025-07-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26776
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc

Published: 2024-04-03Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26777
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fbdev: sis: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.

Published: 2024-04-03Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26778
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8.

Published: 2024-04-03Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26779
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.

Published: 2024-04-03Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26782
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: mptcp: fix double-free on socket dismantle when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to 'inet_opt' for the new socket has the same value as the original one: as a consequence, on program exit it's possible to observe the following splat: BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0 CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: dump_stack_lvl+0x32/0x50 print_report+0xca/0x620 kasan_report_invalid_free+0x64/0x90 __kasan_slab_free+0x1aa/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 rcu_do_batch+0x34e/0xd90 rcu_core+0x559/0xac0 __do_softirq+0x183/0x5a4 irq_exit_rcu+0x12d/0x170 sysvec_apic_timer_interrupt+0x6b/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 RIP: 0010:cpuidle_enter_state+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidle_enter+0x4a/0xa0 do_idle+0x310/0x410 cpu_startup_entry+0x51/0x60 start_secondary+0x211/0x270 secondary_startup_64_no_verify+0x184/0x18b Allocated by task 6853: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 __kmalloc+0x1eb/0x450 cipso_v4_sock_setattr+0x96/0x360 netlbl_sock_setattr+0x132/0x1f0 selinux_netlbl_socket_post_create+0x6c/0x110 selinux_socket_post_create+0x37b/0x7f0 security_socket_post_create+0x63/0xb0 __sock_create+0x305/0x450 __sys_socket_create.part.23+0xbd/0x130 __sys_socket+0x37/0xb0 __x64_sys_socket+0x6f/0xb0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 6858: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x12c/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 subflow_ulp_release+0x1f0/0x250 tcp_cleanup_ulp+0x6e/0x110 tcp_v4_destroy_sock+0x5a/0x3a0 inet_csk_destroy_sock+0x135/0x390 tcp_fin+0x416/0x5c0 tcp_data_queue+0x1bc8/0x4310 tcp_rcv_state_process+0x15a3/0x47b0 tcp_v4_do_rcv+0x2c1/0x990 tcp_v4_rcv+0x41fb/0x5ed0 ip_protocol_deliver_rcu+0x6d/0x9f0 ip_local_deliver_finish+0x278/0x360 ip_local_deliver+0x182/0x2c0 ip_rcv+0xb5/0x1c0 __netif_receive_skb_one_core+0x16e/0x1b0 process_backlog+0x1e3/0x650 __napi_poll+0xa6/0x500 net_rx_action+0x740/0xbb0 __do_softirq+0x183/0x5a4 The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0) The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888485950780: fa fb fb ---truncated---

Published: 2024-04-04Modified: 2025-01-10
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26783
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops: 0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS: 00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14: 0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3: 000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: > > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP: 002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08: 0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 >

Published: 2024-04-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26787
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: stm32: fix DMA API overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path.

Published: 2024-04-04Modified: 2025-03-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26788
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18

Published: 2024-04-04Modified: 2025-04-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26790
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ). Implement this workaround.

Published: 2024-04-04Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26791
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links).

Published: 2024-04-04Modified: 2024-12-20
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-26793
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated---

Published: 2024-04-04Modified: 2024-12-20
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26795
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments

Published: 2024-04-04Modified: 2025-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26798
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fbcon: always restore the old font data in fbcon_do_set_font() Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vc_resize() failed) started restoring old font data upon failure (of vc_resize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcon_do_set_font() performs no restore at all upon failing vc_resize(). This can be reproduced by Syzkaller to crash the system on the next invocation of font_get(). It's rather hard to hit the allocation failure in vc_resize() on the first font_set(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ... So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'old_userfont' and not 'old_data' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.)

Published: 2024-04-04Modified: 2026-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26799
MEDIUM6.2

In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix uninitialized pointer dmactl In the case where __lpass_get_dmactl_handle is called and the driver id dai_id is invalid the pointer dmactl is not being assigned a value, and dmactl contains a garbage value since it has not been initialized and so the null check may not work. Fix this to initialize dmactl to NULL. One could argue that modern compilers will set this to zero, but it is useful to keep this initialized as per the same way in functions __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params. Cleans up clang scan build warning: sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch]

Published: 2024-04-04Modified: 2025-04-04
CVSS 3.xMEDIUM 6.2
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26801
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash.

Published: 2024-04-04Modified: 2024-12-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26802
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic. To secure against this possible crash, set workqueue variable to NULL when destroying workqueue. Log/backtrace from crash goes as follows: [88.031977]------------[ cut here ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 [88.032251]---[ end trace e70de432e4d5c2c0 ]--- [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter. [88.036359]------------[ cut here ]------------ [88.036519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part.0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] process_one_work+0x1d8/0x4a0 [88.036573] worker_thread+0x54/0x408 [88.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+0x10/0x20 [88.036588]---[ end trace e70de432e4d5c2c1 ]--- [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004

Published: 2024-04-04Modified: 2025-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26803
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths.

Published: 2024-04-04Modified: 2025-04-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26804
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely.

Published: 2024-04-04Modified: 2025-03-21
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-26805
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]: netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data(). This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects uninitialized memory area when copying the data. This patch resolved this issue by correct the len from `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated---

Published: 2024-04-04Modified: 2025-02-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26809
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: release elements in clone only from destroy path Clone already always provides a current view of the lookup table, use it to destroy the set, otherwise it is possible to destroy elements twice. This fix requires: 212ed75dc5fb ("netfilter: nf_tables: integrate pipapo into commit protocol") which came after: 9827a0e6e23b ("netfilter: nft_set_pipapo: release elements in clone from abort path").

Published: 2024-04-04Modified: 2025-03-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26810
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Lock external INTx masking ops Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code. In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration. This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows.

Published: 2024-04-05Modified: 2025-04-08
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26812
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Create persistent INTx handler A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending. Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace. As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks.

Published: 2024-04-05Modified: 2025-03-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26813
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index.

Published: 2024-04-05Modified: 2024-12-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26814
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged.

Published: 2024-04-05Modified: 2025-03-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26815
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: proper TCA_TAPRIO_TC_ENTRY_INDEX check taprio_parse_tc_entry() is not correctly checking TCA_TAPRIO_TC_ENTRY_INDEX attribute: int tc; // Signed value tc = nla_get_u32(tb[TCA_TAPRIO_TC_ENTRY_INDEX]); if (tc >= TC_QOPT_MAX_QUEUE) { NL_SET_ERR_MSG_MOD(extack, "TC entry index out of range"); return -ERANGE; } syzbot reported that it could fed arbitary negative values: UBSAN: shift-out-of-bounds in net/sched/sch_taprio.c:1722:18 shift exponent -2147418108 is negative CPU: 0 PID: 5066 Comm: syz-executor367 Not tainted 6.8.0-rc7-syzkaller-00136-gc8a5c731fd12 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_shift_out_of_bounds+0x3c7/0x420 lib/ubsan.c:386 taprio_parse_tc_entry net/sched/sch_taprio.c:1722 [inline] taprio_parse_tc_entries net/sched/sch_taprio.c:1768 [inline] taprio_change+0xb87/0x57d0 net/sched/sch_taprio.c:1877 taprio_init+0x9da/0xc80 net/sched/sch_taprio.c:2134 qdisc_create+0x9d4/0x1190 net/sched/sch_api.c:1355 tc_modify_qdisc+0xa26/0x1e40 net/sched/sch_api.c:1776 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6617 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f1b2dea3759 Code: 48 83 c4 28 c3 e8 d7 19 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd4de452f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f1b2def0390 RCX: 00007f1b2dea3759 RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000004 RBP: 0000000000000003 R08: 0000555500000000 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007ffd4de45340 R13: 00007ffd4de45310 R14: 0000000000000001 R15: 00007ffd4de45340

Published: 2024-04-10Modified: 2025-03-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26816
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map.

Published: 2024-04-10Modified: 2025-03-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26817
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: amdkfd: use calloc instead of kzalloc to avoid integer overflow This uses calloc instead of doing the multiplication which might overflow.

Published: 2024-04-13Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26820
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER handler cannot perform VF register successfully as the register call is received before netvsc_probe is finished. This is because we register register_netdevice_notifier() very early( even before vmbus_driver_register()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvsc_probe.

Published: 2024-04-17Modified: 2025-03-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26825
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free rx_data_reassembly skb on NCI device cleanup rx_data_reassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak. As by design the rx_data_reassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Published: 2024-04-17Modified: 2025-03-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26826
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data re-injection from stale subflow When the MPTCP PM detects that a subflow is stale, all the packet scheduler must re-inject all the mptcp-level unacked data. To avoid acquiring unneeded locks, it first try to check if any unacked data is present at all in the RTX queue, but such check is currently broken, as it uses TCP-specific helper on an MPTCP socket. Funnily enough fuzzers and static checkers are happy, as the accessed memory still belongs to the mptcp_sock struct, and even from a functional perspective the recovery completed successfully, as the short-cut test always failed. A recent unrelated TCP change - commit d5fed5addb2b ("tcp: reorganize tcp_sock fast path variables") - exposed the issue, as the tcp field reorganization makes the mptcp code always skip the re-inection. Fix the issue dropping the bogus call: we are on a slow path, the early optimization proved once again to be evil.

Published: 2024-04-17Modified: 2025-03-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26828
MEDIUM6.7

In the Linux kernel, the following vulnerability has been resolved: cifs: fix underflow in parse_server_interfaces() In this loop, we step through the buffer and after each item we check if the size_left is greater than the minimum size we need. However, the problem is that "bytes_left" is type ssize_t while sizeof() is type size_t. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending.

Published: 2024-04-17Modified: 2025-04-08
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H
References
CVE-2024-26829
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: ir_toy: fix a memleak in irtoy_tx When irtoy_command fails, buf should be freed since it is allocated by irtoy_tx, or there is a memleak.

Published: 2024-04-17Modified: 2025-06-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26830
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-26832
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26833
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak in dm_sw_fini() After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak: unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 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 (crc 6265fd77): [] kmalloc_trace+0x29d/0x340 [] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [] dm_sw_init+0x15/0x2b0 [amdgpu] [] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [] local_pci_probe+0x3e/0x90 [] pci_device_probe+0xc3/0x230 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] do_one_initcall+0x41/0x300 Fix this by freeing dmub_srv after destroying it.

Published: 2024-04-17Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26835
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: set dormant flag on hook register failure We need to set the dormant flag again if we fail to register the hooks. During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks. On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core.

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
References
CVE-2024-26836
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix password opcode ordering for workstations The Lenovo workstations require the password opcode to be run before the attribute value is changed (if Admin password is enabled). Tested on some Thinkpads to confirm they are OK with this order too.

Published: 2024-04-17Modified: 2025-11-25
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26837
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26838
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix KASAN issue with tasklet KASAN testing revealed the following issue assocated with freeing an IRQ. [50006.466686] Call Trace: [50006.466691] [50006.489538] dump_stack+0x5c/0x80 [50006.493475] print_address_description.constprop.6+0x1a/0x150 [50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.511644] kasan_report.cold.11+0x7f/0x118 [50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.528232] irdma_process_ceq+0xb2/0x400 [irdma] [50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma] [50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma] [50006.545306] tasklet_action_common.isra.14+0x148/0x2c0 [50006.551096] __do_softirq+0x1d0/0xaf8 [50006.555396] irq_exit_rcu+0x219/0x260 [50006.559670] irq_exit+0xa/0x20 [50006.563320] smp_apic_timer_interrupt+0x1bf/0x690 [50006.568645] apic_timer_interrupt+0xf/0x20 [50006.573341] The issue is that a tasklet could be pending on another core racing the delete of the irq. Fix by insuring any scheduled tasklet is killed after deleting the irq.

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26839
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix a memleak in init_credit_return When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered.

Published: 2024-04-17Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26840
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix memory leak in cachefiles_add_cache() The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 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 (crc ea38a44b): [] kmem_cache_alloc+0x2d5/0x370 [] prepare_creds+0x26/0x2e0 [] cachefiles_determine_cache_security+0x1f/0x120 [] cachefiles_add_cache+0x13c/0x3a0 [] cachefiles_daemon_write+0x146/0x1c0 [] vfs_write+0xcb/0x520 [] ksys_write+0x69/0xf0 [] do_syscall_64+0x72/0x140 [] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks.

Published: 2024-04-17Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26841
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Update cpu_sibling_map when disabling nonboot CPUs Update cpu_sibling_map when disabling nonboot CPUs by defining & calling clear_cpu_sibling_map(), otherwise we get such errors on SMT systems: jump label: negative count! WARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100 CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 pc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20 a0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280 a4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001 t0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000 t4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964 t8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8 s1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040 s5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006 ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1c (LIE=2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 Stack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000 90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0 900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001 0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0 0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f 6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000 900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000 0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4 0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c ... Call Trace: [<9000000000224528>] show_stack+0x48/0x1a0 [<900000000179afc8>] dump_stack_lvl+0x78/0xa0 [<9000000000263ed0>] __warn+0x90/0x1a0 [<90000000017419b8>] report_bug+0x1b8/0x280 [<900000000179c564>] do_bp+0x264/0x420 [<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100 [<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300 [<9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0 [<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240 [<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0 [<900000000029a720>] kthread+0x140/0x160 [<9000000000222288>] ret_from_kernel_thread+0xc/0xa4

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26842
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix shift issue in ufshcd_clear_cmd() When task_tag >= 32 (in MCQ mode) and sizeof(unsigned int) == 4, 1U << task_tag will out of bounds for a u32 mask. Fix this up to prevent SHIFT_ISSUE (bitwise shifts that are out of bounds for their data type). [name:debug_monitors&]Unexpected kernel BRK exception at EL1 [name:traps&]Internal error: BRK handler: 00000000f2005514 [#1] PREEMPT SMP [name:mediatek_cpufreq_hw&]cpufreq stop DVFS log done [name:mrdump&]Kernel Offset: 0x1ba5800000 from 0xffffffc008000000 [name:mrdump&]PHYS_OFFSET: 0x80000000 [name:mrdump&]pstate: 22400005 (nzCv daif +PAN -UAO) [name:mrdump&]pc : [0xffffffdbaf52bb2c] ufshcd_clear_cmd+0x280/0x288 [name:mrdump&]lr : [0xffffffdbaf52a774] ufshcd_wait_for_dev_cmd+0x3e4/0x82c [name:mrdump&]sp : ffffffc0081471b0 Workqueue: ufs_eh_wq_0 ufshcd_err_handler Call trace: dump_backtrace+0xf8/0x144 show_stack+0x18/0x24 dump_stack_lvl+0x78/0x9c dump_stack+0x18/0x44 mrdump_common_die+0x254/0x480 [mrdump] ipanic_die+0x20/0x30 [mrdump] notify_die+0x15c/0x204 die+0x10c/0x5f8 arm64_notify_die+0x74/0x13c do_debug_exception+0x164/0x26c el1_dbg+0x64/0x80 el1h_64_sync_handler+0x3c/0x90 el1h_64_sync+0x68/0x6c ufshcd_clear_cmd+0x280/0x288 ufshcd_wait_for_dev_cmd+0x3e4/0x82c ufshcd_exec_dev_cmd+0x5bc/0x9ac ufshcd_verify_dev_init+0x84/0x1c8 ufshcd_probe_hba+0x724/0x1ce0 ufshcd_host_reset_and_restore+0x260/0x574 ufshcd_reset_and_restore+0x138/0xbd0 ufshcd_err_handler+0x1218/0x2f28 process_one_work+0x5fc/0x1140 worker_thread+0x7d8/0xe20 kthread+0x25c/0x468 ret_from_fork+0x10/0x20

Published: 2024-04-17Modified: 2025-03-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26843
MEDIUM6.0

In the Linux kernel, the following vulnerability has been resolved: efi: runtime: Fix potential overflow of soft-reserved region size md_size will have been narrowed if we have >= 4GB worth of pages in a soft-reserved region.

Published: 2024-04-17Modified: 2025-04-29
CVSS 3.xMEDIUM 6.0
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-26844
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: block: Fix WARNING in _copy_from_iter Syzkaller reports a warning in _copy_from_iter because an iov_iter is supposedly used in the wrong direction. The reason is that syzcaller managed to generate a request with a transfer direction of SG_DXFER_TO_FROM_DEV. This instructs the kernel to copy user buffers into the kernel, read into the copied buffers and then copy the data back to user space. Thus the iovec is used in both directions. Detect this situation in the block layer and construct a new iterator with the correct direction for the copy-in.

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26845
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Add TMF to tmr_list handling An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core.

Published: 2024-04-17Modified: 2026-01-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26846
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. This is done by flushing the nvme_delete_wq workqueue. While at it, remove the unused nvme_fc_wq workqueue too.

Published: 2024-04-17Modified: 2025-03-21
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26849
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netlink: add nla be16/32 types to minlen array BUG: KMSAN: uninit-value in nla_validate_range_unsigned lib/nlattr.c:222 [inline] BUG: KMSAN: uninit-value in nla_validate_int_range lib/nlattr.c:336 [inline] BUG: KMSAN: uninit-value in validate_nla lib/nlattr.c:575 [inline] BUG: KMSAN: uninit-value in __nla_validate_parse+0x2e20/0x45c0 lib/nlattr.c:631 nla_validate_range_unsigned lib/nlattr.c:222 [inline] nla_validate_int_range lib/nlattr.c:336 [inline] validate_nla lib/nlattr.c:575 [inline] ... The message in question matches this policy: [NFTA_TARGET_REV] = NLA_POLICY_MAX(NLA_BE32, 255), but because NLA_BE32 size in minlen array is 0, the validation code will read past the malformed (too small) attribute. Note: Other attributes, e.g. BITFIELD32, SINT, UINT.. are also missing: those likely should be added too.

Published: 2024-04-17Modified: 2026-04-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26851
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: Add protection for bmp length out of range UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts that are out of bounds for their data type. vmlinux get_bitmap(b=75) + 712 vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956 vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216 vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812 vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216 vmlinux DecodeRasMessage() + 304 vmlinux ras_help() + 684 vmlinux nf_confirm() + 188 Due to abnormal data in skb->data, the extension bitmap length exceeds 32 when decoding ras message then uses the length to make a shift operation. It will change into negative after several loop. UBSAN load could detect a negative shift as an undefined behaviour and reports exception. So we add the protection to avoid the length exceeding 32. Or else it will return out of range error and stop decoding.

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26852
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/ipv6: avoid possible UAF in ip6_route_mpath_notify() syzbot found another use-after-free in ip6_route_mpath_notify() [1] Commit f7225172f25a ("net/ipv6: prevent use after free in ip6_route_mpath_notify") was not able to fix the root cause. We need to defer the fib6_info_release() calls after ip6_route_mpath_notify(), in the cleanup phase. [1] BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037 CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x167/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x180 mm/kasan/report.c:601 rt6_fill_node+0x1460/0x1ac0 inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184 ip6_route_mpath_notify net/ipv6/route.c:5198 [inline] ip6_route_multipath_add net/ipv6/route.c:5404 [inline] inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 Allocated by task 23037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3981 [inline] __kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758 ip6_route_multipath_add net/ipv6/route.c:5298 [inline] inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 Freed by task 16: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640 poison_slab_object+0xa6/0xe0 m ---truncated---

Published: 2024-04-17Modified: 2025-03-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26853
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: igc: avoid returning frame twice in XDP_REDIRECT When a frame can not be transmitted in XDP_REDIRECT (e.g. due to a full queue), it is necessary to free it by calling xdp_return_frame_rx_napi. However, this is the responsibility of the caller of the ndo_xdp_xmit (see for example bq_xmit_all in kernel/bpf/devmap.c) and thus calling it inside igc_xdp_xmit (which is the ndo_xdp_xmit of the igc driver) as well will lead to memory corruption. In fact, bq_xmit_all expects that it can return all frames after the last successfully transmitted one. Therefore, break for the first not transmitted frame, but do not call xdp_return_frame_rx_napi in igc_xdp_xmit. This is equally implemented in other Intel drivers such as the igb. There are two alternatives to this that were rejected: 1. Return num_frames as all the frames would have been transmitted and release them inside igc_xdp_xmit. While it might work technically, it is not what the return value is meant to represent (i.e. the number of SUCCESSFULLY transmitted packets). 2. Rework kernel/bpf/devmap.c and all drivers to support non-consecutively dropped packets. Besides being complex, it likely has a negative performance impact without a significant gain since it is anyway unlikely that the next frame can be transmitted if the previous one was dropped. The memory corruption can be reproduced with the following script which leads to a kernel panic after a few seconds. It basically generates more traffic than a i225 NIC can transmit and pushes it via XDP_REDIRECT from a virtual interface to the physical interface where frames get dropped. #!/bin/bash INTERFACE=enp4s0 INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex` sudo ip link add dev veth1 type veth peer name veth2 sudo ip link set up $INTERFACE sudo ip link set up veth1 sudo ip link set up veth2 cat << EOF > redirect.bpf.c SEC("prog") int redirect(struct xdp_md *ctx) { return bpf_redirect($INTERFACE_IDX, 0); } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o sudo ip link set veth2 xdp obj redirect.bpf.o cat << EOF > pass.bpf.c SEC("prog") int pass(struct xdp_md *ctx) { return XDP_PASS; } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o sudo ip link set $INTERFACE xdp obj pass.bpf.o cat << EOF > trafgen.cfg { /* Ethernet Header */ 0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, const16(ETH_P_IP), /* IPv4 Header */ 0b01000101, 0, # IPv4 version, IHL, TOS const16(1028), # IPv4 total length (UDP length + 20 bytes (IP header)) const16(2), # IPv4 ident 0b01000000, 0, # IPv4 flags, fragmentation off 64, # IPv4 TTL 17, # Protocol UDP csumip(14, 33), # IPv4 checksum /* UDP Header */ 10, 0, 1, 1, # IP Src - adapt as needed 10, 0, 1, 2, # IP Dest - adapt as needed const16(6666), # UDP Src Port const16(6666), # UDP Dest Port const16(1008), # UDP length (UDP header 8 bytes + payload length) csumudp(14, 34), # UDP checksum /* Payload */ fill('W', 1000), } EOF sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26855
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() The function ice_bridge_setlink() may encounter a NULL pointer dereference if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently in nla_for_each_nested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration.

Published: 2024-04-17Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26856
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: sparx5: Fix use after free inside sparx5_del_mact_entry Based on the static analyzis of the code it looks like when an entry from the MAC table was removed, the entry was still used after being freed. More precise the vid of the mac_entry was used after calling devm_kfree on the mac_entry. The fix consists in first using the vid of the mac_entry to delete the entry from the HW and after that to free it.

Published: 2024-04-17Modified: 2025-03-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26857
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: geneve: make sure to pull inner header in geneve_rx() syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Published: 2024-04-17Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26859
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: net/bnx2x: Prevent access to a freed page in page_pool Fix race condition leading to system crash during EEH error handling During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2x_free_rx_sge() 799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp, 800 struct bnx2x_fastpath *fp, u16 index) 801 { 802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index]; 803 struct page *page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 To solve this issue, we need to verify page pool allocations before freeing.

Published: 2024-04-17Modified: 2025-03-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26861
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: wireguard: receive: annotate data-race around receiving_counter.counter Syzkaller with KCSAN identified a data-race issue when accessing keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE() annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ...

Published: 2024-04-17Modified: 2025-04-02
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26862
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: packet: annotate data-races around ignore_outgoing ignore_outgoing is read locklessly from dev_queue_xmit_nit() and packet_getsockopt() Add appropriate READ_ONCE()/WRITE_ONCE() annotations. syzbot reported: BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0: packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c:2311 [inline] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 [inline] dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 worker_thread+0x526/0x730 kernel/workqueue.c:3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet

Published: 2024-04-17Modified: 2025-03-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26863
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in hsr_get_node() KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue. This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag.

Published: 2024-04-17Modified: 2025-01-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26865
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: rds: tcp: Fix use-after-free of net in reqsk_timer_handler(). syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1]. syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows: 18:26:22 executing program 1: r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async) The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT. So, the scenario would be: 1. unshare(CLONE_NEWNET) creates a per netns tcp listener in rds_tcp_listen_init(). 2. syz-executor connect()s to it and creates a reqsk. 3. syz-executor exit()s immediately. 4. netns is dismantled. [0] 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1] 6. listener is freed after RCU grace period. [2] Basically, reqsk assumes that the listener guarantees netns safety until all reqsk timers are expired by holding the listener's refcount. However, this was not the case for kernel sockets. Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inet_twsk_purge()") fixed this issue only for per-netns ehash. Let's apply the same fix for the global ehash. [0]: ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146) inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119) __sock_create (net/socket.c:1572) rds_tcp_listen_init (net/rds/tcp_listen.c:279) rds_tcp_init_net (net/rds/tcp.c:577) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:340) copy_net_ns (net/core/net_namespace.c:497) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4)) ksys_unshare (kernel/fork.c:3429) __x64_sys_unshare (kernel/fork.c:3496) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) ... WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) [1]: BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) Read of size 8 at addr ffff88801b370400 by task swapper/0/0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) kasan_report (mm/kasan/report.c:603) inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) run_timer_softirq (kernel/time/timer.c:2053) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14)) Allocated by task 258 on cpu 0 at 83.612050s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) __kasan_slab_alloc (mm/kasan/common.c:343) kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867) copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_name ---truncated---

Published: 2024-04-17Modified: 2025-01-07
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26866
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: lpspi: Avoid potential use-after-free in probe() fsl_lpspi_probe() is allocating/disposing memory manually with spi_alloc_host()/spi_alloc_target(), but uses devm_spi_register_controller(). In case of error after the latter call the memory will be explicitly freed in the probe function by spi_controller_put() call, but used afterwards by "devm" management outside probe() (spi_unregister_controller() <- devm_spi_unregister() below). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 ... Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork

Published: 2024-04-17Modified: 2025-01-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26868
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfs: fix panic when nfs4_ff_layout_prepare_ds() fails We've been seeing the following panic in production BUG: kernel NULL pointer dereference, address: 0000000000000065 PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0 RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles] Call Trace: ? __die+0x78/0xc0 ? page_fault_oops+0x286/0x380 ? __rpc_execute+0x2c3/0x470 [sunrpc] ? rpc_new_task+0x42/0x1c0 [sunrpc] ? exc_page_fault+0x5d/0x110 ? asm_exc_page_fault+0x22/0x30 ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles] ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles] ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles] pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4] pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4] ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles] nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles] ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles] __nfs_pageio_add_request+0x154/0x6c0 [nfs] nfs_pageio_add_request+0x26b/0x380 [nfs] nfs_do_writepage+0x111/0x1e0 [nfs] nfs_writepages_callback+0xf/0x30 [nfs] write_cache_pages+0x17f/0x380 ? nfs_pageio_init_write+0x50/0x50 [nfs] ? nfs_writepages+0x6d/0x210 [nfs] ? nfs_writepages+0x6d/0x210 [nfs] nfs_writepages+0x125/0x210 [nfs] do_writepages+0x67/0x220 ? generic_perform_write+0x14b/0x210 filemap_fdatawrite_wbc+0x5b/0x80 file_write_and_wait_range+0x6d/0xc0 nfs_file_fsync+0x81/0x170 [nfs] ? nfs_file_mmap+0x60/0x60 [nfs] __x64_sys_fsync+0x53/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Inspecting the core with drgn I was able to pull this >>> prog.crashed_thread().stack_trace()[0] #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27 >>> prog.crashed_thread().stack_trace()[0]['idx'] (u32)1 >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds (struct nfs4_ff_layout_ds *)0xffffffffffffffed This is clear from the stack trace, we call nfs4_ff_layout_prepare_ds() which could error out initializing the mirror_ds, and then we go to clean it all up and our check is only for if (!mirror->mirror_ds). This is inconsistent with the rest of the users of mirror_ds, which have if (IS_ERR_OR_NULL(mirror_ds)) to keep from tripping over this exact scenario. Fix this up in ff_layout_cancel_io() to make sure we don't panic when we get an error. I also spot checked all the other instances of checking mirror_ds and we appear to be doing the correct checks everywhere, only unconditionally dereferencing mirror_ds when we know it would be valid.

Published: 2024-04-17Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26869
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate meta inode pages forcely Below race case can cause data corruption: Thread A GC thread - gc_data_segment - ra_data_block - locked meta_inode page - f2fs_inplace_write_data - invalidate_mapping_pages : fail to invalidate meta_inode page due to lock failure or dirty|writeback status - f2fs_submit_page_bio : write last dirty data to old blkaddr - move_data_block - load old data from meta_inode page - f2fs_submit_page_write : write old data to new blkaddr Because invalidate_mapping_pages() will skip invalidating page which has unclear status including locked, dirty, writeback and so on, so we need to use truncate_inode_pages_range() instead of invalidate_mapping_pages() to make sure meta_inode page will be dropped.

Published: 2024-04-17Modified: 2025-05-07
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26870
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000) Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug. Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size.

Published: 2024-04-17Modified: 2025-04-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26872
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete.

Published: 2024-04-17Modified: 2025-03-04
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26874
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use.

Published: 2024-04-17Modified: 2025-03-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26875
MEDIUM6.4

In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix uaf in pvr2_context_set_notify [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272 Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 [Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue. [Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue.

Published: 2024-04-17Modified: 2025-03-21
CVSS 3.xMEDIUM 6.4
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26876
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/bridge: adv7511: fix crash on irq during probe Moved IRQ registration down to end of adv7511_probe(). If an IRQ already is pending during adv7511_probe (before adv7511_cec_init) then cec_received_msg_ts could crash using uninitialized data: Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5 Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP Call trace: cec_received_msg_ts+0x48/0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 irq_thread+0x14c/0x238 kthread+0x190/0x1a8

Published: 2024-04-17Modified: 2025-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26877
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: xilinx - call finalize with bh disabled When calling crypto_finalize_request, BH should be disabled to avoid triggering the following calltrace: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : crypto_finalize_request+0xa0/0x118 lr : crypto_finalize_request+0x104/0x118 sp : ffffffc085353ce0 x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688 x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000 Call trace: crypto_finalize_request+0xa0/0x118 crypto_finalize_aead_request+0x18/0x30 zynqmp_handle_aes_req+0xcc/0x388 crypto_pump_work+0x168/0x2d8 kthread_worker_fn+0xfc/0x3a0 kthread+0x118/0x138 ret_from_fork+0x10/0x20 irq event stamp: 40 hardirqs last enabled at (39): [] _raw_spin_unlock_irqrestore+0x70/0xb0 hardirqs last disabled at (40): [] el1_dbg+0x28/0x90 softirqs last enabled at (36): [] kernel_neon_begin+0x8c/0xf0 softirqs last disabled at (34): [] kernel_neon_begin+0x60/0xf0 ---[ end trace 0000000000000000 ]---

Published: 2024-04-17Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26878
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue.

Published: 2024-04-17Modified: 2025-01-14
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26879
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: meson: Add missing clocks to axg_clk_regmaps Some clocks were missing from axg_clk_regmaps, which caused kernel panic during cat /sys/kernel/debug/clk/clk_summary [ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc ... [ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.436900] pc : regmap_read+0x1c/0x88 [ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.445611] sp : ffff800082f1b690 [ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70 [ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000 [ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000 [ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff [ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000 [ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100 [ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24 [ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710 [ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000 [ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000 [ 57.519615] Call trace: [ 57.522030] regmap_read+0x1c/0x88 [ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.530050] clk_core_is_enabled+0x44/0x120 [ 57.534190] clk_summary_show_subtree+0x154/0x2f0 [ 57.538847] clk_summary_show_subtree+0x220/0x2f0 [ 57.543505] clk_summary_show_subtree+0x220/0x2f0 [ 57.548162] clk_summary_show_subtree+0x220/0x2f0 [ 57.552820] clk_summary_show_subtree+0x220/0x2f0 [ 57.557477] clk_summary_show_subtree+0x220/0x2f0 [ 57.562135] clk_summary_show_subtree+0x220/0x2f0 [ 57.566792] clk_summary_show_subtree+0x220/0x2f0 [ 57.571450] clk_summary_show+0x84/0xb8 [ 57.575245] seq_read_iter+0x1bc/0x4b8 [ 57.578954] seq_read+0x8c/0xd0 [ 57.582059] full_proxy_read+0x68/0xc8 [ 57.585767] vfs_read+0xb0/0x268 [ 57.588959] ksys_read+0x70/0x108 [ 57.592236] __arm64_sys_read+0x24/0x38 [ 57.596031] invoke_syscall+0x50/0x128 [ 57.599740] el0_svc_common.constprop.0+0x48/0xf8 [ 57.604397] do_el0_svc+0x28/0x40 [ 57.607675] el0_svc+0x34/0xb8 [ 57.610694] el0t_64_sync_handler+0x13c/0x158 [ 57.615006] el0t_64_sync+0x190/0x198 [ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00) [ 57.624668] ---[ end trace 0000000000000000 ]--- [jbrunet: add missing Fixes tag]

Published: 2024-04-17Modified: 2025-01-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26880
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dm: call the resume method on internal suspend There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the origin_postsuspend function. The second call attempts to remove the "hash_list" entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it calls the preresume and resume methods of the table's targets. If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return errors. We can't return success, because then the "resume" and "postsuspend" methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0 RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ? do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ? __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0 [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot] dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0 [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10 [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead ---[ end trace 0000000000000000 ]---

Published: 2024-04-17Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26881
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is received on HIP08 devices The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash: [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge] [ 5889.279101] sp : ffff800012c3bc50 [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000 [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480 [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000 [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000 [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080 [ 5889.378857] Call trace: [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] __handle_domain_irq+0x88/0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.460717] cpu_startup_entry+0x30/0xfc [ 5889.465523] secondary_start_kernel+0x158/0x1ec [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [ 5889.477950] SMP: stopping secondary CPUs [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95 [ 5890.522951] Starting crashdump kernel...

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26882
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Published: 2024-04-17Modified: 2024-12-20
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26883
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check on 32-bit arches The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. The commit in the fixes tag actually attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before rounding does not have this problem.

Published: 2024-04-17Modified: 2025-03-07
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26884
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on 32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup.

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26885
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation.

Published: 2024-04-17Modified: 2025-01-24
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26886
MEDIUM6.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: af_bluetooth: Fix deadlock Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

Published: 2024-04-17Modified: 2025-03-21
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26889
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix possible buffer overflow struct hci_dev_info has a fixed size name[8] field so in the event that hdev->name is bigger than that strcpy would attempt to write past its size, so this fixes this problem by switching to use strscpy.

Published: 2024-04-17Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26891
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected For those endpoint devices connect to system via hotplug capable ports, users could request a hot reset to the device by flapping device's link through setting the slot's link control register, as pciehp_ist() DLLSC interrupt sequence response, pciehp will unload the device driver and then power it off. thus cause an IOMMU device-TLB invalidation (Intel VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence target device to be sent and deadly loop to retry that request after ITE fault triggered in interrupt context. That would cause following continuous hard lockup warning and system hang [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822623] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005 [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000 [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200 [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004 [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) knlGS:0000000000000000 [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0 [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 4223.822628] PKRU: 55555554 [ 4223.822628] Call Trace: [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0 [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 [ 4223.822629] intel_iommu_release_device+0x1f/0x30 [ 4223.822629] iommu_release_device+0x33/0x60 [ 4223.822629] iommu_bus_notifier+0x7f/0x90 [ 4223.822630] blocking_notifier_call_chain+0x60/0x90 [ 4223.822630] device_del+0x2e5/0x420 [ 4223.822630] pci_remove_bus_device+0x70/0x110 [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 [ 4223.822631] pciehp_disable_slot+0x6b/0x100 [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 [ 4223.822631] pciehp_ist+0x176/0x180 [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 [ 4223.822632] irq_thread_fn+0x19/0x50 [ 4223.822632] irq_thread+0x104/0x190 [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0 [ 4223.822633] kthread+0x114/0x130 [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 [ 4223.822633] ret_from_fork+0x1f/0x30 [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822634] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822634] Call Trace: [ 4223.822634] [ 4223.822635] dump_stack+0x6d/0x88 [ 4223.822635] panic+0x101/0x2d0 [ 4223.822635] ? ret_from_fork+0x11/0x30 [ 4223.822635] nmi_panic.cold.14+0xc/0xc [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81 [ 4223.822636] __perf_event_overflow+0x4f/0xf0 [ 4223.822636] handle_pmi_common ---truncated---

Published: 2024-04-17Modified: 2025-05-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26893
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in SMC transport cleanup path When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash.

Published: 2024-04-17Modified: 2025-01-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26894
MEDIUM6.0

In the Linux kernel, the following vulnerability has been resolved: ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit() After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak: unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 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 (crc 8836a742): [] kmalloc_trace+0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+0x2d/0x50 Fix this by freeing the CPU idle device after unregistering it.

Published: 2024-04-17Modified: 2025-03-21
CVSS 3.xMEDIUM 6.0
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-26895
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces wilc_netdev_cleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver: echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind ================================================================== BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86 CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from print_report+0x154/0x500 print_report from kasan_report+0xac/0xd8 kasan_report from wilc_netdev_cleanup+0x508/0x5cc wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec wilc_bus_remove from spi_remove+0x8c/0xac spi_remove from device_release_driver_internal+0x434/0x5f8 device_release_driver_internal from unbind_store+0xbc/0x108 unbind_store from kernfs_fop_write_iter+0x398/0x584 kernfs_fop_write_iter from vfs_write+0x728/0xf88 vfs_write from ksys_write+0x110/0x1e4 ksys_write from ret_fast_syscall+0x0/0x1c [...] Allocated by task 1: kasan_save_track+0x30/0x5c __kasan_kmalloc+0x8c/0x94 __kmalloc_node+0x1cc/0x3e4 kvmalloc_node+0x48/0x180 alloc_netdev_mqs+0x68/0x11dc alloc_etherdev_mqs+0x28/0x34 wilc_netdev_ifc_init+0x34/0x8ec wilc_cfg80211_init+0x690/0x910 wilc_bus_probe+0xe0/0x4a0 spi_probe+0x158/0x1b0 really_probe+0x270/0xdf4 __driver_probe_device+0x1dc/0x580 driver_probe_device+0x60/0x140 __driver_attach+0x228/0x5d4 bus_for_each_dev+0x13c/0x1a8 bus_add_driver+0x2a0/0x608 driver_register+0x24c/0x578 do_one_initcall+0x180/0x310 kernel_init_freeable+0x424/0x484 kernel_init+0x20/0x148 ret_from_fork+0x14/0x28 Freed by task 86: kasan_save_track+0x30/0x5c kasan_save_free_info+0x38/0x58 __kasan_slab_free+0xe4/0x140 kfree+0xb0/0x238 device_release+0xc0/0x2a8 kobject_put+0x1d4/0x46c netdev_run_todo+0x8fc/0x11d0 wilc_netdev_cleanup+0x1e4/0x5cc wilc_bus_remove+0xc8/0xec spi_remove+0x8c/0xac device_release_driver_internal+0x434/0x5f8 unbind_store+0xbc/0x108 kernfs_fop_write_iter+0x398/0x584 vfs_write+0x728/0xf88 ksys_write+0x110/0x1e4 ret_fast_syscall+0x0/0x1c [...] David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needs_free_netdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list. Fix this use-after-free thanks to two mechanisms: - navigate in the list with list_for_each_entry_safe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with list_del_rcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev) Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vif_mutex lock), we do not need to use RCU list API, that's why we can benefit from list_for_each_entry_safe. [1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/

Published: 2024-04-17Modified: 2025-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26896
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix memory leak when starting AP Kmemleak reported this error: unreferenced object 0xd73d1180 (size 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s) 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 1e 00 01 00 00 00 00 00 ................ backtrace: [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac [<127bdd74>] __alloc_skb+0x144/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 [<69954f45>] __sys_sendmsg+0x64/0xa8 unreferenced object 0xce087000 (size 1024): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<9a993714>] __kmalloc_track_caller+0x230/0x600 [] kmalloc_reserve.constprop.0+0x30/0x74 [] __alloc_skb+0xa0/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 However, since the kernel is build optimized, it seems the stack is not accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue is obvious in this function: memory allocated by ieee80211_beacon_get() is never released. Fixing this leak makes kmemleak happy.

Published: 2024-04-17Modified: 2025-03-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26897
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data structures have been fully initialised by the time it runs. However, because of the order in which things are initialised, this is not guaranteed to be the case, because the device is exposed to the USB subsystem before the ath9k driver initialisation is completed. We already committed a partial fix for this in commit: 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()") However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event tasklet, pairing it with an "initialisation complete" bit in the TX struct. It seems syzbot managed to trigger the race for one of the other commands as well, so let's just move the existing synchronisation bit to cover the whole tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside ath9k_tx_init()).

Published: 2024-04-17Modified: 2025-12-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26898
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts This patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial code is finished. But the net_device ifp will still be used in later tx()->dev_queue_xmit() in kthread. Which means that the dev_put(ifp) should NOT be called in the success path of skb initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into use-after-free because the net_device is freed. This patch removed the dev_put(ifp) in the success path in aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26901
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem.

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26902
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: perf: RISCV: Fix panic on pmu overflow handler (1 << idx) of int is not desired when setting bits in unsigned long overflowed_ctrs, use BIT() instead. This panic happens when running 'perf record -e branches' on sophgo sg2042. [ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ 273.320851] Oops [#1] [ 273.323179] Modules linked in: [ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9 [ 273.332521] Hardware name: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0 [ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978 [ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70 [ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000 [ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015 [ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a [ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0 [ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210 [ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098 [ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca [ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8 [ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d [ 273.434512] [] riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.441169] [] handle_percpu_devid_irq+0x98/0x1ee [ 273.447562] [] generic_handle_domain_irq+0x28/0x36 [ 273.454151] [] riscv_intc_irq+0x36/0x4e [ 273.459659] [] handle_riscv_irq+0x4a/0x74 [ 273.465442] [] do_irq+0x62/0x92 [ 273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [ 273.477921] ---[ end trace 0000000000000000 ]--- [ 273.482630] Kernel panic - not syncing: Fatal exception in interrupt

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26903
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling rfcomm_recv_frame in rfcomm_process_rx.

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26906
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault() When trying to use copy_from_kernel_nofault() to read vsyscall page through a bpf program, the following oops was reported: BUG: unable to handle page fault for address: ffffffffff600000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:copy_from_kernel_nofault+0x6f/0x110 ...... Call Trace: ? copy_from_kernel_nofault+0x6f/0x110 bpf_probe_read_kernel+0x1d/0x50 bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d trace_call_bpf+0xc5/0x1c0 perf_call_bpf_enter.isra.0+0x69/0xb0 perf_syscall_enter+0x13e/0x200 syscall_trace_enter+0x188/0x1c0 do_syscall_64+0xb5/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 ...... ---[ end trace 0000000000000000 ]--- The oops is triggered when: 1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall page and invokes copy_from_kernel_nofault() which in turn calls __get_user_asm(). 2) Because the vsyscall page address is not readable from kernel space, a page fault exception is triggered accordingly. 3) handle_page_fault() considers the vsyscall page address as a user space address instead of a kernel space address. This results in the fix-up setup by bpf not being applied and a page_fault_oops() is invoked due to SMAP. Considering handle_page_fault() has already considered the vsyscall page address as a userspace address, fix the problem by disallowing vsyscall page read for copy_from_kernel_nofault().

Published: 2024-04-17Modified: 2025-09-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26907
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated---

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26910
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback.

Published: 2024-04-17Modified: 2024-11-21
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26915
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reset IH OVERFLOW_CLEAR bit Allows us to detect subsequent IH ring buffer overflows as well.

Published: 2024-04-17Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26916
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Revert "drm/amd: flush any delayed gfxoff on suspend entry" commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/end_use ring callbacks") caused GFXOFF control to be used more heavily and the codepath that was removed from commit 0dee72639533 ("drm/amd: flush any delayed gfxoff on suspend entry") now can be exercised at suspend again. Users report that by using GNOME to suspend the lockscreen trigger will cause SDMA traffic and the system can deadlock. This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.

Published: 2024-04-17Modified: 2025-09-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26917
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock" This reverts commit 1a1975551943f681772720f639ff42fbaa746212. This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave". Instead, a work queue should be used, and will be addressed in a separate commit.

Published: 2024-04-17Modified: 2025-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26919
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: Fix debugfs directory leak The ULPI per-device debugfs root is named after the ulpi device's parent, but ulpi_unregister_interface tries to remove a debugfs directory named after the ulpi device itself. This results in the directory sticking around and preventing subsequent (deferred) probes from succeeding. Change the directory name to match the ulpi device.

Published: 2024-04-17Modified: 2025-09-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26920
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tracing/trigger: Fix to return error if failed to alloc snapshot Fix register_snapshot_trigger() to return error code if it failed to allocate a snapshot instead of 0 (success). Unless that, it will register snapshot trigger without an error.

Published: 2024-04-17Modified: 2025-09-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26921
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: inet: inet_defrag: prevent sk release while still in use ip_local_out() and other functions can pass skb->sk as function argument. If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released. This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline. Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing. A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()") [..] net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one. If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly. We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used. Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this: If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow. This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered. This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue. In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine. In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.

Published: 2024-04-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26922
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate the parameters of bo mapping operations more clearly Verify the parameters of amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.

Published: 2024-04-23Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26923
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix garbage collector racing against connect() Garbage collector does not take into account the risk of embryo getting enqueued during the garbage collection. If such embryo has a peer that carries SCM_RIGHTS, two consecutive passes of scan_children() may see a different set of children. Leading to an incorrectly elevated inflight count, and then a dangling pointer within the gc_inflight_list. sockets are AF_UNIX/SOCK_STREAM S is an unconnected socket L is a listening in-flight socket bound to addr, not in fdtable V's fd will be passed via sendmsg(), gets inflight count bumped connect(S, addr) sendmsg(S, [V]); close(V) __unix_gc() ---------------- ------------------------- ----------- NS = unix_create1() skb1 = sock_wmalloc(NS) L = unix_find_other(addr) unix_state_lock(L) unix_peer(S) = NS // V count=1 inflight=0 NS = unix_peer(S) skb2 = sock_alloc() skb_queue_tail(NS, skb2[V]) // V became in-flight // V count=2 inflight=1 close(V) // V count=1 inflight=1 // GC candidate condition met for u in gc_inflight_list: if (total_refs == inflight_refs) add u to gc_candidates // gc_candidates={L, V} for u in gc_candidates: scan_children(u, dec_inflight) // embryo (skb1) was not // reachable from L yet, so V's // inflight remains unchanged __skb_queue_tail(L, skb1) unix_state_unlock(L) for u in gc_candidates: if (u.inflight) scan_children(u, inc_inflight_move_tail) // V count=1 inflight=2 (!) If there is a GC-candidate listening socket, lock/unlock its state. This makes GC wait until the end of any ongoing connect() to that socket. After flipping the lock, a possibly SCM-laden embryo is already enqueued. And if there is another embryo coming, it can not possibly carry SCM_RIGHTS. At this point, unix_inflight() can not happen because unix_gc_lock is already taken. Inflight graph remains unaffected.

Published: 2024-04-25Modified: 2025-12-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26924
MEDIUM5.9

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano)

Published: 2024-04-25Modified: 2025-11-04
CVSS 3.xMEDIUM 5.9
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26925
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path The commit mutex should not be released during the critical section between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC worker could collect expired objects and get the released commit lock within the same GC sequence. nf_tables_module_autoload() temporarily releases the mutex to load module dependencies, then it goes back to replay the transaction again. Move it at the end of the abort phase after nft_gc_seq_end() is called.

Published: 2024-04-25Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26926
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: binder: check offset alignment in binder_get_object() Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying txn") introduced changes to how binder objects are copied. In doing so, it unintentionally removed an offset alignment check done through calls to binder_alloc_copy_from_buffer() -> check_buffer(). These calls were replaced in binder_get_object() with copy_from_user(), so now an explicit offset alignment check is needed here. This avoids later complications when unwinding the objects gets harder. It is worth noting this check existed prior to commit 7a67a39320df ("binder: add function to copy binder object from buffer"), likely removed due to redundancy at the time.

Published: 2024-04-25Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26927
HIGH8.4

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Add some bounds checking to firmware data Smatch complains about "head->full_size - head->header_size" can underflow. To some extent, we're always going to have to trust the firmware a bit. However, it's easy enough to add a check for negatives, and let's add a upper bounds check as well.

Published: 2024-04-28Modified: 2025-03-21
CVSS 3.xHIGH 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26928
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-04-28Modified: 2025-12-01
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26931
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix command flush on cable pull System crash due to command failed to flush back to SCSI layer. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0 ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc] qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200. ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1 ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0 ? __switch_to+0x10c/0x450 ? process_one_work+0x1a7/0x360 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201. ? worker_thread+0x1ce/0x390 ? create_worker+0x1a0/0x1a0 qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70 ? kthread+0x10a/0x120 qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8 ? set_kthread_struct+0x40/0x40 qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed. ? ret_from_fork+0x1f/0x40 qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout The system was under memory stress where driver was not able to allocate an SRB to carry out error recovery of cable pull. The failure to flush causes upper layer to start modifying scsi_cmnd. When the system frees up some memory, the subsequent cable pull trigger another command flush. At this point the driver access a null pointer when attempting to DMA unmap the SGL. Add a check to make sure commands are flush back on session tear down to prevent the null pointer access.

Published: 2024-05-01Modified: 2025-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26933
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in port "disable" sysfs attribute The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration: Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and device_del() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then. But the disable_show() or disable_store() routine can't return until after it has acquired the lock. The resulting deadlock can be avoided by calling sysfs_break_active_protection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hub_get().

Published: 2024-05-01Modified: 2025-03-07
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26934
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in usb_deauthorize_interface() Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device. The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished. The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback. Reported-and-tested by: Yue Sun Reported by: xingwei lee

Published: 2024-05-01Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26935
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix unremoved procfs host directory regression Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release(). But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example. Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure): usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376 The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case. This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26936
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate request buffer size in smb2_allocate_rsp_buf() The response buffer should be allocated in smb2_allocate_rsp_buf before validating request. But the fields in payload as well as smb2 header is used in smb2_allocate_rsp_buf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26937
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Reset queue_priority_hint on parking Originally, with strict in order execution, we could complete execution only when the queue was empty. Preempt-to-busy allows replacement of an active request that may complete before the preemption is processed by HW. If that happens, the request is retired from the queue, but the queue_priority_hint remains set, preventing direct submission until after the next CS interrupt is processed. This preempt-to-busy race can be triggered by the heartbeat, which will also act as the power-management barrier and upon completion allow us to idle the HW. We may process the completion of the heartbeat, and begin parking the engine before the CS event that restores the queue_priority_hint, causing us to fail the assertion that it is MIN. <3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1)) <0>[ 166.210781] Dumping ftrace buffer: <0>[ 166.210795] --------------------------------- ... <0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 } <0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646 <0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0 <0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659 <0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40 <0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 } <0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2 <0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin <0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2 <0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin <0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660 <0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns } <0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked <0>[ 167.303534] -0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040 <0>[ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns } <0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns } <0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1)) <0>[ 167.303811] --------------------------------- <4>[ 167.304722] ------------[ cut here ]------------ <2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283! <4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1 <4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 <4>[ 167.304738] Workqueue: i915-unordered retire_work_handler [i915] <4>[ 16 ---truncated---

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26938
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() If we have no VBT, or the VBT didn't declare the encoder in question, we won't have the 'devdata' for the encoder. Instead of oopsing just bail early. We won't be able to tell whether the port is DP++ or not, but so be it. (cherry picked from commit 26410896206342c8a80d2b027923e9ee7d33b733)

Published: 2024-05-01Modified: 2026-01-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26939
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: drm/i915/vma: Fix UAF on destroy against retire race Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915] [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 ... [161.361347] debug_object_free+0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] release_references+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] [161.363129] __gt_park+0x121/0x230 [i915] [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915] That has been tracked down to be happening when another thread is deactivating the VMA inside __active_retire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool. We could prevent from that race by serializing i915_active_fini() with __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from being used, e.g. from __i915_vma_retire() called at the end of __active_retire(), after that VMA has been already freed by a concurrent i915_vma_destroy() on return from the i915_active_fini(). Then, we should rather fix the issue at the VMA level, not in i915_active. Since __i915_vma_parked() is called from __gt_park() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for __active_retire() to complete before that wakeref is released and the GT parked. I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915_active_fini() from a dropped i915_vma_release(), called on last put of the removed VMA kref, to i915_vma_parked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915_active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation"). A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intel_context for a GT associated with its VM, and indirectly on that intel_context's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation. Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since __i915_vma_retire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed. v7: Add inline comments with justifications for: - using untracked variants of intel_gt_pm_get/put() (Nirmoy), - using async variant of _put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since __i915_vma_active/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915_vma is not safe, and there is no other good place for that. Use untracked variants of intel_gt_pm_get/put_async(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated---

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26940
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed The driver creates /sys/kernel/debug/dri/0/mob_ttm even when the corresponding ttm_resource_manager is not allocated. This leads to a crash when trying to read from this file. Add a check to create mob_ttm, system_mob_ttm, and gmr_ttm debug file only when the corresponding ttm_resource_manager is allocated. crash> bt PID: 3133409 TASK: ffff8fe4834a5000 CPU: 3 COMMAND: "grep" #0 [ffffb954506b3b20] machine_kexec at ffffffffb2a6bec3 #1 [ffffb954506b3b78] __crash_kexec at ffffffffb2bb598a #2 [ffffb954506b3c38] crash_kexec at ffffffffb2bb68c1 #3 [ffffb954506b3c50] oops_end at ffffffffb2a2a9b1 #4 [ffffb954506b3c70] no_context at ffffffffb2a7e913 #5 [ffffb954506b3cc8] __bad_area_nosemaphore at ffffffffb2a7ec8c #6 [ffffb954506b3d10] do_page_fault at ffffffffb2a7f887 #7 [ffffb954506b3d40] page_fault at ffffffffb360116e [exception RIP: ttm_resource_manager_debug+0x11] RIP: ffffffffc04afd11 RSP: ffffb954506b3df0 RFLAGS: 00010246 RAX: ffff8fe41a6d1200 RBX: 0000000000000000 RCX: 0000000000000940 RDX: 0000000000000000 RSI: ffffffffc04b4338 RDI: 0000000000000000 RBP: ffffb954506b3e08 R8: ffff8fee3ffad000 R9: 0000000000000000 R10: ffff8fe41a76a000 R11: 0000000000000001 R12: 00000000ffffffff R13: 0000000000000001 R14: ffff8fe5bb6f3900 R15: ffff8fe41a6d1200 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffffb954506b3e00] ttm_resource_manager_show at ffffffffc04afde7 [ttm] #9 [ffffb954506b3e30] seq_read at ffffffffb2d8f9f3 RIP: 00007f4c4eda8985 RSP: 00007ffdbba9e9f8 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 000000000037e000 RCX: 00007f4c4eda8985 RDX: 000000000037e000 RSI: 00007f4c41573000 RDI: 0000000000000003 RBP: 000000000037e000 R8: 0000000000000000 R9: 000000000037fe30 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4c41573000 R13: 0000000000000003 R14: 00007f4c41572010 R15: 0000000000000003 ORIG_RAX: 0000000000000000 CS: 0033 SS: 002b

Published: 2024-05-01Modified: 2025-03-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26943
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: handle kcalloc() allocation failure The kcalloc() in nouveau_dmem_evict_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations.

Published: 2024-05-01Modified: 2025-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26946
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address Read from an unsafe address with copy_from_kernel_nofault() in arch_adjust_kprobe_addr() because this function is used before checking the address is in text or not. Syzcaller bot found a bug and reported the case if user specifies inaccessible data area, arch_adjust_kprobe_addr() will cause a kernel panic. [ mingo: Clarified the comment. ]

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26947
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000 the crash backtrace like: Unable to handle kernel paging request at virtual address bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Tainted: G O 5.10.0 #1 Hardware name: Generic DT based system PC is at b15_flush_kern_dcache_area+0x24/0x3c LR is at __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) from (set_pte_at+0x28/0x54) (set_pte_at) from (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4) (__mmap_region) from (__do_mmap_mm+0x3ec/0x440) (__do_mmap_mm) from (do_mmap+0x50/0x58) (do_mmap) from (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c) Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Kernel panic - not syncing: Fatal exception So check if PG_reserved was set to solve this issue. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26950
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: access device through ctx instead of peer The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers.

Published: 2024-05-01Modified: 2025-03-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26951
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: check for dangling peer via is_dead instead of empty list If all peers are removed via wg_peer_remove_all(), rather than setting peer_list to empty, the peer is added to a temporary list with a head on the stack of wg_peer_remove_all(). If a netlink dump is resumed and the cursored peer is one that has been removed via wg_peer_remove_all(), it will iterate from that peer and then attempt to dump freed peers. Fix this by instead checking peer->is_dead, which was explictly created for this purpose. Also move up the device_update_lock lockdep assertion, since reading is_dead relies on that. It can be reproduced by a small script like: echo "Setting config..." ip link add dev wg0 type wireguard wg setconf wg0 /big-config ( while true; do echo "Showing config..." wg showconf wg0 > /dev/null done ) & sleep 4 wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n") Resulting in: BUG: KASAN: slab-use-after-free in __lock_acquire+0x182a/0x1b20 Read of size 8 at addr ffff88811956ec70 by task wg/59 CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5 Call Trace: dump_stack_lvl+0x47/0x70 print_address_description.constprop.0+0x2c/0x380 print_report+0xab/0x250 kasan_report+0xba/0xf0 __lock_acquire+0x182a/0x1b20 lock_acquire+0x191/0x4b0 down_read+0x80/0x440 get_peer+0x140/0xcb0 wg_get_device_dump+0x471/0x1130

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26952
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial out-of-bounds when buffer offset is invalid I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.

Published: 2024-05-01Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26953
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: esp: fix bad handling of pages from page_pool When the skb is reorganized during esp_output (!esp->inline), the pages coming from the original skb fragments are supposed to be released back to the system through put_page. But if the skb fragment pages are originating from a page_pool, calling put_page on them will trigger a page_pool leak which will eventually result in a crash. This leak can be easily observed when using CONFIG_DEBUG_VM and doing ipsec + gre (non offloaded) forwarding: BUG: Bad page state in process ksoftirqd/16 pfn:1451b6 page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6 flags: 0x200000000000000(node=0|zone=2) page_type: 0xffffffff() raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000 raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: page_pool leak Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validate_xmit_xfrm+0x313/0x370 ? validate_xmit_skb+0x1d/0x330 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 gro_cell_poll+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 The suggested fix is to introduce a new wrapper (skb_page_unref) that covers page refcounting for page_pool pages as well.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26955
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: nilfs2: prevent kernel bug at submit_bh_wbc() Fix a bug where nilfs_get_block() returns a successful status when searching and inserting the specified block both fail inconsistently. If this inconsistent behavior is not due to a previously fixed bug, then an unexpected race is occurring, so return a temporary error -EAGAIN instead. This prevents callers such as __block_write_begin_int() from requesting a read into a buffer that is not mapped, which would cause the BUG_ON check for the BH_Mapped flag in submit_bh_wbc() to fail.

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26956
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix failure to detect DAT corruption in btree and direct mappings Patch series "nilfs2: fix kernel bug at submit_bh_wbc()". This resolves a kernel BUG reported by syzbot. Since there are two flaws involved, I've made each one a separate patch. The first patch alone resolves the syzbot-reported bug, but I think both fixes should be sent to stable, so I've tagged them as such. This patch (of 2): Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data to a nilfs2 file system whose metadata is corrupted. There are two flaws involved in this issue. The first flaw is that when nilfs_get_block() locates a data block using btree or direct mapping, if the disk address translation routine nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata corruption, it can be passed back to nilfs_get_block(). This causes nilfs_get_block() to misidentify an existing block as non-existent, causing both data block lookup and insertion to fail inconsistently. The second flaw is that nilfs_get_block() returns a successful status in this inconsistent state. This causes the caller __block_write_begin_int() or others to request a read even though the buffer is not mapped, resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc() failing. This fixes the first issue by changing the return value to code -EINVAL when a conversion using DAT fails with code -ENOENT, avoiding the conflicting condition that leads to the kernel bug described above. Here, code -EINVAL indicates that metadata corruption was detected during the block lookup, which will be properly handled as a file system error and converted to -EIO when passing through the nilfs2 bmap layer.

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26957
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix reference counting on zcrypt card objects Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use. This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated---

Published: 2024-05-01Modified: 2025-03-20
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26958
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: nfs: fix UAF in direct writes In production we have been hitting the following warning consistently ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 This is because we're completing the nfs_direct_request twice in a row. The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice. The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a nfs_commit_begin(); nfs_commit_end(); Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths. Fix this by using the same pattern for the commit requests. Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping.

Published: 2024-05-01Modified: 2025-08-28
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26960
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache(). Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this): --8<----- __swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0. So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries. Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry. Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.] Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()? --8<-----

Published: 2024-05-01Modified: 2025-03-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26961
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: mac802154: fix llsec key resources release in mac802154_llsec_key_del mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion: refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del(): unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [] __kmem_cache_alloc_node+0x1e2/0x2d0 [] kmalloc_trace+0x25/0xc0 [] mac802154_llsec_key_add+0xac9/0xcf0 [] ieee802154_add_llsec_key+0x5a/0x80 [] nl802154_add_llsec_key+0x426/0x5b0 [] genl_family_rcv_msg_doit+0x1fe/0x2f0 [] genl_rcv_msg+0x531/0x7d0 [] netlink_rcv_skb+0x169/0x440 [] genl_rcv+0x28/0x40 [] netlink_unicast+0x53c/0x820 [] netlink_sendmsg+0x93b/0xe60 [] ____sys_sendmsg+0xac5/0xca0 [] ___sys_sendmsg+0x11d/0x1c0 [] __sys_sendmsg+0xfa/0x1d0 [] do_syscall_64+0x45/0xf0 [] entry_SYSCALL_64_after_hwframe+0x6e/0x76 Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu(). Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses. Found by Linux Verification Center (linuxtesting.org).

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26963
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3-am62: fix module unload/reload behavior As runtime PM is enabled, the module can be runtime suspended when .remove() is called. Do a pm_runtime_get_sync() to make sure module is active before doing any register operations. Doing a pm_runtime_put_sync() should disable the refclk so no need to disable it again. Fixes the below warning at module removel. [ 39.705310] ------------[ cut here ]------------ [ 39.710004] clk:162:3 already disabled [ 39.713941] WARNING: CPU: 0 PID: 921 at drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 We called of_platform_populate() in .probe() so call the cleanup function of_platform_depopulate() in .remove(). Get rid of the now unnnecessary dwc3_ti_remove_core(). Without this, module re-load doesn't work properly.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26964
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Add error handling in xhci_map_urb_for_dma Currently xhci_map_urb_for_dma() creates a temporary buffer and copies the SG list to the new linear buffer. But if the kzalloc_node() fails, then the following sg_pcopy_to_buffer() can lead to crash since it tries to memcpy to NULL pointer. So return -ENOMEM if kzalloc returns null pointer.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26965
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26966
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26969
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26970
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested.

Published: 2024-05-01Modified: 2025-03-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26973
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fat: fix uninitialized field in nostale filehandles When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length.

Published: 2024-05-01Modified: 2025-03-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26974
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26976
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated---

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26977
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pci_iounmap(): Fix MMIO mapping leak The #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentally also guards iounmap(), which means MMIO mappings are leaked. Move the guard so we call iounmap() for MMIO mappings.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26978
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: serial: max310x: fix NULL pointer dereference in I2C instantiation When trying to instantiate a max14830 device from userspace: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device we get the following error: Unable to handle kernel NULL pointer dereference at virtual address... ... Call trace: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error message.

Published: 2024-05-01Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26980
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf().

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26981
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26982
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix]

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-26983
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bootconfig: use memblock_free_late to free xbc memory to buddy On the time to free xbc memory in xbc_exit(), memblock may has handed over memory to buddy allocator. So it doesn't make sense to free memory back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86. Following KASAN logs shows this case. This patch fixes the xbc memory free problem by calling memblock_free() in early xbc init error rewind path and calling memblock_free_late() in xbc exit path to free memory to buddy allocator. [ 9.410890] ================================================================== [ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260 [ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1 [ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5 [ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023 [ 9.460789] Call Trace: [ 9.463518] [ 9.465859] dump_stack_lvl+0x53/0x70 [ 9.469949] print_report+0xce/0x610 [ 9.473944] ? __virt_addr_valid+0xf5/0x1b0 [ 9.478619] ? memblock_isolate_range+0x12d/0x260 [ 9.483877] kasan_report+0xc6/0x100 [ 9.487870] ? memblock_isolate_range+0x12d/0x260 [ 9.493125] memblock_isolate_range+0x12d/0x260 [ 9.498187] memblock_phys_free+0xb4/0x160 [ 9.502762] ? __pfx_memblock_phys_free+0x10/0x10 [ 9.508021] ? mutex_unlock+0x7e/0xd0 [ 9.512111] ? __pfx_mutex_unlock+0x10/0x10 [ 9.516786] ? kernel_init_freeable+0x2d4/0x430 [ 9.521850] ? __pfx_kernel_init+0x10/0x10 [ 9.526426] xbc_exit+0x17/0x70 [ 9.529935] kernel_init+0x38/0x1e0 [ 9.533829] ? _raw_spin_unlock_irq+0xd/0x30 [ 9.538601] ret_from_fork+0x2c/0x50 [ 9.542596] ? __pfx_kernel_init+0x10/0x10 [ 9.547170] ret_from_fork_asm+0x1a/0x30 [ 9.551552] [ 9.555649] The buggy address belongs to the physical page: [ 9.561875] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x45dd30 [ 9.570821] flags: 0x200000000000000(node=0|zone=2) [ 9.576271] page_type: 0xffffffff() [ 9.580167] raw: 0200000000000000 ffffea0011774c48 ffffea0012ba1848 0000000000000000 [ 9.588823] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 [ 9.597476] page dumped because: kasan: bad access detected [ 9.605362] Memory state around the buggy address: [ 9.610714] ffff88845dd2ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.618786] ffff88845dd2ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.626857] >ffff88845dd30000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.634930] ^ [ 9.638534] ffff88845dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.654675] ==================================================================

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26984
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nouveau: fix instmem race condition around ptr stores Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26987
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled When I did hard offline test with hugetlb pages, below deadlock occurs: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted ------------------------------------------------------ bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60 but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pcp_batch_high_lock); lock(cpu_hotplug_lock); lock(pcp_batch_high_lock); rlock(cpu_hotplug_lock); *** DEADLOCK *** 5 locks held by bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 stack backtrace: CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00 In short, below scene breaks the ---truncated---

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26988
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: init/main.c: Fix potential static_command_line memory overflow We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for static_command_line, but the strings copied into static_command_line are extra_command_line and command_line, rather than extra_command_line and boot_command_line. When strlen(command_line) > strlen(boot_command_line), static_command_line will overflow. This patch just recovers strlen(command_line) which was miss-consolidated with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add checks for the return value of memblock_alloc*()")

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26989
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Fix level3 translation fault in swsusp_save() On arm64 machines, swsusp_save() faults if it attempts to access MEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI when booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n: Unable to handle kernel paging request at virtual address ffffff8000000000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76 Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : swsusp_save+0x280/0x538 lr : swsusp_save+0x280/0x538 sp : ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0 x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001 x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e Call trace: swsusp_save+0x280/0x538 swsusp_arch_suspend+0x148/0x190 hibernation_snapshot+0x240/0x39c hibernate+0xc4/0x378 state_store+0xf0/0x10c kobj_attr_store+0x14/0x24 The reason is swsusp_save() -> copy_data_pages() -> page_is_saveable() -> kernel_page_present() assuming that a page is always present when can_set_direct_map() is false (all of rodata_full, debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false), irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions should not be saved during hibernation. This problem was introduced by changes to the pfn_valid() logic in commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify pfn_valid()"). Similar to other architectures, drop the !can_set_direct_map() check in kernel_page_present() so that page_is_savable() skips such pages. [catalin.marinas@arm.com: rework commit message]

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26992
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: KVM: x86/pmu: Disable support for adaptive PEBS Drop support for virtualizing adaptive PEBS, as KVM's implementation is architecturally broken without an obvious/easy path forward, and because exposing adaptive PEBS can leak host LBRs to the guest, i.e. can leak host kernel addresses to the guest. Bug #1 is that KVM doesn't account for the upper 32 bits of IA32_FIXED_CTR_CTRL when (re)programming fixed counters, e.g fixed_ctrl_field() drops the upper bits, reprogram_fixed_counters() stores local variables as u8s and truncates the upper bits too, etc. Bug #2 is that, because KVM _always_ sets precise_ip to a non-zero value for PEBS events, perf will _always_ generate an adaptive record, even if the guest requested a basic record. Note, KVM will also enable adaptive PEBS in individual *counter*, even if adaptive PEBS isn't exposed to the guest, but this is benign as MSR_PEBS_DATA_CFG is guaranteed to be zero, i.e. the guest will only ever see Basic records. Bug #3 is in perf. intel_pmu_disable_fixed() doesn't clear the upper bits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and intel_pmu_enable_fixed() effectively doesn't clear ICL_FIXED_0_ADAPTIVE either. I.e. perf _always_ enables ADAPTIVE counters, regardless of what KVM requests. Bug #4 is that adaptive PEBS *might* effectively bypass event filters set by the host, as "Updated Memory Access Info Group" records information that might be disallowed by userspace via KVM_SET_PMU_EVENT_FILTER. Bug #5 is that KVM doesn't ensure LBR MSRs hold guest values (or at least zeros) when entering a vCPU with adaptive PEBS, which allows the guest to read host LBRs, i.e. host RIPs/addresses, by enabling "LBR Entries" records. Disable adaptive PEBS support as an immediate fix due to the severity of the LBR leak in particular, and because fixing all of the bugs will be non-trivial, e.g. not suitable for backporting to stable kernels. Note! This will break live migration, but trying to make KVM play nice with live migration would be quite complicated, wouldn't be guaranteed to work (i.e. KVM might still kill/confuse the guest), and it's not clear that there are any publicly available VMMs that support adaptive PEBS, let alone live migrate VMs that support adaptive PEBS, e.g. QEMU doesn't support PEBS in any capacity.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
References
CVE-2024-26993
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs: sysfs: Fix reference leak in sysfs_break_active_protection() The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26994
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: speakup: Avoid crash on very long word In case a console is set up really large and contains a really long word (> 256 characters), we have to stop before the length of the word buffer.

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-26996
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled. After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled. As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL. And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object. Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory. [function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm [function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-26999
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: serial/pmac_zilog: Remove flawed mitigation for rx irq flood The mitigation was intended to stop the irq completely. That may be better than a hard lock-up but it turns out that you get a crash anyway if you're using pmac_zilog as a serial console: ttyPZ0: pmz: rx irq flood ! BUG: spinlock recursion on CPU#0, swapper/0 That's because the pr_err() call in pmz_receive_chars() results in pmz_console_write() attempting to lock a spinlock already locked in pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal BUG splat. The spinlock in question is the one in struct uart_port. Even when it's not fatal, the serial port rx function ceases to work. Also, the iteration limit doesn't play nicely with QEMU, as can be seen in the bug report linked below. A web search for other reports of the error message "pmz: rx irq flood" didn't produce anything. So I don't think this code is needed any more. Remove it.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27000
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: serial: mxs-auart: add spinlock around changing cts state The uart_handle_cts_change() function in serial_core expects the caller to hold uport->lock. For example, I have seen the below kernel splat, when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth] (...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4 [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210 (...)

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27001
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: comedi: vmk80xx: fix incomplete endpoint checking While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xx_find_usb_endpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'panic_on_warn' set on them. Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usb_find_common_endpoints() and ensuring that only expected endpoint types are present. This patch has not been tested on real hardware. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ... Similar issue also found by Syzkaller:

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27002
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: Do a runtime PM get on controllers during probe mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack: CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock() CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock() Do a runtime PM get at the probe function to make sure clk_register() won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg, do this on all mediatek clock controller probings because we don't believe this would cause any regression. Verified on MT8183 and MT8192 Chromebooks.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27003
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree for clk_summary Similar to the previous commit, we should make sure that all devices are runtime resumed before printing the clk_summary through debugfs. Failure to do so would result in a deadlock if the thread is resuming a device to print clk state and that device is also runtime resuming in another thread, e.g the screen is turning on and the display driver is starting up. We remove the calls to clk_pm_runtime_{get,put}() in this path because they're superfluous now that we know the devices are runtime resumed. This also squashes a bug where the return value of clk_pm_runtime_get() wasn't checked, leading to an RPM count underflow on error paths.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27004
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree during disable_unused Doug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20 The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread. This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again. Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27005
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: interconnect: Don't access req_list while it's being manipulated The icc_lock mutex was split into separate icc_lock and icc_bw_lock mutexes in [1] to avoid lockdep splats. However, this didn't adequately protect access to icc_node::req_list. The icc_set_bw() function will eventually iterate over req_list while only holding icc_bw_lock, but req_list can be modified while only holding icc_lock. This causes races between icc_set_bw(), of_icc_get(), and icc_put(). Example A: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); icc_put(path_b) mutex_lock(&icc_lock); aggregate_requests() hlist_for_each_entry(r, ... hlist_del(... Example B: CPU0 CPU1 ---- ---- icc_set_bw(path_a) mutex_lock(&icc_bw_lock); path_b = of_icc_get() of_icc_get_by_index() mutex_lock(&icc_lock); path_find() path_init() aggregate_requests() hlist_for_each_entry(r, ... hlist_add_head(... Fix this by ensuring icc_bw_lock is always held before manipulating icc_node::req_list. The additional places icc_bw_lock is held don't perform any memory allocations, so we should still be safe from the original lockdep splats that motivated the separate locks. [1] commit af42269c3523 ("interconnect: Fix locking for runpm vs reclaim")

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-27008
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm: nv04: Fix out of bounds access When Output Resource (dcb->or) value is assigned in fabricate_dcb_output(), there may be out of bounds access to dac_users array in case dcb->or is zero because ffs(dcb->or) is used as index there. The 'or' argument of fabricate_dcb_output() must be interpreted as a number of bit to set, not value. Utilize macros from 'enum nouveau_or' in calls instead of hardcoding. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-05-01Modified: 2025-12-01
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27009
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: s390/cio: fix race condition during online processing A race condition exists in ccw_device_set_online() that can cause the online process to fail, leaving the affected device in an inconsistent state. As a result, subsequent attempts to set that device online fail with return code ENODEV. The problem occurs when a path verification request arrives after a wait for final device state completed, but before the result state is evaluated. Fix this by ensuring that the CCW-device lock is held between determining final state and checking result state. Note that since: commit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers") path verification requests are much more likely to occur during boot, resulting in an increased chance of this race condition occurring.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27013
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tun: limit printing rate when illegal packet received by tun dev vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27014
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent deadlock while disabling aRFS When disabling aRFS under the `priv->state_lock`, any scheduled aRFS works are canceled using the `cancel_work_sync` function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the `state_lock` which is already acquired. The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules. Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled. Kernel log: ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I ------------------------------------------------------ ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0 but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27015
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: incorrect pppoe tuple pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27016
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate pppoe header Ensure there is sufficient room to access the protocol field of the PPPoe header. Validate it once before the flowtable lookup, then use a helper function to access protocol field.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27019
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-27020
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process.

Published: 2024-05-01Modified: 2025-11-04
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27022
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: fork: defer linking file vma until vma is fully initialized Thorvald reported a WARNING [1]. And the root cause is below race: CPU 1 CPU 2 fork hugetlbfs_fallocate dup_mmap hugetlbfs_punch_hole i_mmap_lock_write(mapping); vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. i_mmap_unlock_write(mapping); hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! i_mmap_lock_write(mapping); hugetlb_vmdelete_list vma_interval_tree_foreach hugetlb_vma_trylock_write -- Vma_lock is cleared. tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! hugetlb_vma_unlock_write -- Vma_lock is assigned!!! i_mmap_unlock_write(mapping); hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside i_mmap_rwsem lock while vma lock can be used in the same time. Fix this by deferring linking file vma until vma is fully initialized. Those vmas should be initialized first before they can be used.

Published: 2024-05-01Modified: 2026-04-11
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27023
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: md: Fix missing release of 'active_io' for flush submit_flushes atomic_set(&mddev->flush_pending, 1); rdev_for_each_rcu(rdev, mddev) atomic_inc(&mddev->flush_pending); bi->bi_end_io = md_end_flush submit_bio(bi); /* flush io is done first */ md_end_flush if (atomic_dec_and_test(&mddev->flush_pending)) percpu_ref_put(&mddev->active_io) -> active_io is not released if (atomic_dec_and_test(&mddev->flush_pending)) -> missing release of active_io For consequence, mddev_suspend() will wait for 'active_io' to be zero forever. Fix this problem by releasing 'active_io' in submit_flushes() if 'flush_pending' is decreased to zero.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27024
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/rds: fix WARNING in rds_conn_connect_if_down If connection isn't established yet, get_mr() will fail, trigger connection after get_mr().

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27025
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nbd: null check for nla_nest_start nla_nest_start() may fail and return NULL. Insert a check and set errno based on other call sites within the same source code.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27028
MEDIUM6.5

In the Linux kernel, the following vulnerability has been resolved: spi: spi-mt65xx: Fix NULL pointer access in interrupt handler The TX buffer in spi_transfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes. Add a check to trans->tx_buf before using it.

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
References
CVE-2024-27030
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Use separate handlers for interrupts For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-27032
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential panic during recovery During recovery, if FAULT_BLOCK is on, it is possible that f2fs_reserve_new_block() will return -ENOSPC during recovery, then it may trigger panic. Also, if fault injection rate is 1 and only FAULT_BLOCK fault type is on, it may encounter deadloop in loop of block reservation. Let's change as below to fix these issues: - remove bug_on() to avoid panic. - limit the loop count of block reservation to avoid potential deadloop.

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-27034
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover normal cluster write with cp_rwsem When we overwrite compressed cluster w/ normal cluster, we should not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data will be corrupted if partial blocks were persisted before CP & SPOR, due to cluster metadata wasn't updated atomically.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27035
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to guarantee persisting compressed blocks by CP If data block in compressed cluster is not persisted with metadata during checkpoint, after SPOR, the data may be corrupted, let's guarantee to write compressed page by checkpoint.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27037
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: zynq: Prevent null pointer dereference caused by kmalloc failure The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen. This patch uses a stack variable to replace the kmalloc().

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27038
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: Fix clk_core_get NULL dereference It is possible for clk_core_get to dereference a NULL in the following sequence: clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw() __clk_get_hw() can return NULL which is dereferenced by clk_core_get() at hw->core. Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clk_lookups") the check IS_ERR_OR_NULL() was performed which would have caught the NULL. Reading the description of this function it talks about returning NULL but that cannot be so at the moment. Update the function to check for hw before dereferencing it and return NULL if hw is NULL.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27039
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: clk: hisilicon: hi3559a: Fix an erroneous devm_kfree() 'p_clk' is an array allocated just before the for loop for all clk that need to be registered. It is incremented at each loop iteration. If a clk_register() call fails, 'p_clk' may point to something different from what should be freed. The best we can do, is to avoid this wrong release of memory.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27041
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini() Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL before the call to dc_enable_dmub_notifications(), check beforehand to ensure there will not be a possible NULL-ptr-deref there. Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in 'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy(). Clean up by combining them all under one 'if'. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27043
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27044
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()' The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27045
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()' Tell snprintf() to store at most 10 bytes in the output buffer instead of 30. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27046
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfp: flower: handle acti_netdevs allocation failure The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen. This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27047
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: phy: fix phy_get_internal_delay accessing an empty array The phy_get_internal_delay function could try to access to an empty array in the case that the driver is calling phy_get_internal_delay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >= 0. As there is already delay < 0 test just before, the test could only be size == 0.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27051
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27052
HIGH7.4

In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xHIGH 7.4
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27053
CRITICAL9.1

In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix RCU usage in connect path With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning: ============================= WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted ----------------------------- drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcu_dereference_check() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4 wilc_parse_join_bss_param from connect+0x2c4/0x648 connect from cfg80211_connect+0x30c/0xb74 cfg80211_connect from nl80211_connect+0x860/0xa94 nl80211_connect from genl_rcv_msg+0x3fc/0x59c genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8 netlink_rcv_skb from genl_rcv+0x2c/0x3c genl_rcv from netlink_unicast+0x3b0/0x550 netlink_unicast from netlink_sendmsg+0x368/0x688 netlink_sendmsg from ____sys_sendmsg+0x190/0x430 ____sys_sendmsg from ___sys_sendmsg+0x110/0x158 ___sys_sendmsg from sys_sendmsg+0xe8/0x150 sys_sendmsg from ret_fast_syscall+0x0/0x1c This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilc_parse_join_bss_param under the critical section, just use the critical section to copy ies data

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-27054
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix double module refcount decrement Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same.

Published: 2024-05-01Modified: 2025-05-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27057
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend When the system is suspended while audio is active, the sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during suspend the DSP is turned off, streams will be re-started after resume. If the firmware crashes during while audio is running (or when we reset the stream before suspend) then the sof_ipc4_set_multi_pipeline_state() will fail with IPC error and the state change is interrupted. This will cause misalignment between the kernel and firmware state on next DSP boot resulting errors returned by firmware for IPC messages, eventually failing the audio resume. On stream close the errors are ignored so the kernel state will be corrected on the next DSP boot, so the second boot after the DSP panic. If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then state parameter is SOF_IPC4_PIPE_RESET and only in this case. Treat a forced pipeline reset similarly to how we treat a pcm_free by ignoring error on state sending to allow the kernel's state to be consistent with the state the firmware will have after the next boot.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27062
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nouveau: lock the client object tree. It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] [ 4562.099573] ? die_addr+0x36/0x90 [ 4562.099583] ? exc_general_protection+0x246/0x4a0 [ 4562.099593] ? asm_exc_general_protection+0x26/0x30 [ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356] __do_fault+0x32/0x150 [ 4562.100362] do_fault+0x7c/0x560 [ 4562.100369] __handle_mm_fault+0x800/0xc10 [ 4562.100382] handle_mm_fault+0x17c/0x3e0 [ 4562.100388] do_user_addr_fault+0x208/0x860 [ 4562.100395] exc_page_fault+0x7f/0x200 [ 4562.100402] asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27065
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: do not compare internal table flags on updates Restore skipping transaction if table update does not modify flags.

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27072
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: usbtv: Remove useless locks in usbtv_video_free() Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device. Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming. [hverkuil: fix minor spelling mistake in log message]

Published: 2024-05-01Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27073
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: ttpci: fix two memleaks in budget_av_attach When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations.

Published: 2024-05-01Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27074
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: go7007: fix a memleak in go7007_load_encoder In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27075
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: avoid stack overflow warnings with clang A previous patch worked around a KASAN issue in stv0367, now a similar problem showed up with clang: drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe) Rework the stv0367_writereg() function to be simpler and mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get duplicated on the stack when KASAN_STACK is enabled.

Published: 2024-05-01Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27076
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak Free the memory allocated in v4l2_ctrl_handler_init on release.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27077
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27078
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: fix some memleaks in tpg_alloc In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0.

Published: 2024-05-01Modified: 2024-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27388
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths.

Published: 2024-05-01Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27389
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pstore: inode: Only d_invalidate() is needed Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. ---

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27390
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down() As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27391
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: do not realloc workqueue everytime an interface is added Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to set the interface name in the workqueue name. However, while the driver needs only one workqueue, the wilc_netdev_ifc_init is called each time we add an interface over a phy, which in turns overwrite the workqueue with a new one. This can be observed with the following commands: for i in $(seq 0 10) do iw phy phy0 interface add wlan1 type managed iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/R-wlan1 102 kworker/R-wlan1 105 kworker/R-wlan1 108 kworker/R-wlan1 111 kworker/R-wlan1 114 kworker/R-wlan1 117 kworker/R-wlan1 120 kworker/R-wlan1 123 kworker/R-wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Fix this leakage by putting back hif_workqueue allocation in wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to set it lowercase, however it is not attached to a specific netdev, so enforcing netdev name in the name is not so relevant. Still, enrich the name with the wiphy name to make it clear which phy is using the workqueue.

Published: 2024-05-01Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27393
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")). This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks").

Published: 2024-05-14Modified: 2025-04-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27395
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix Use-After-Free in ovs_ct_exit Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal of ovs_ct_limit_exit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe.

Published: 2024-05-14Modified: 2025-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27396
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: gtp: Fix Use-After-Free in gtp_dellink Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe.

Published: 2024-05-14Modified: 2025-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27398
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout When the sco connection is established and then, the sco socket is releasing, timeout_work will be scheduled to judge whether the sco disconnection is timeout. The sock will be deallocated later, but it is dereferenced again in sco_sock_timeout. As a result, the use-after-free bugs will happen. The root cause is shown below: Cleanup Thread | Worker Thread sco_sock_release | sco_sock_close | __sco_sock_close | sco_sock_set_timer | schedule_delayed_work | sco_sock_kill | (wait a time) sock_put(sk) //FREE | sco_sock_timeout | sock_hold(sk) //USE The KASAN report triggered by POC is shown below: [ 95.890016] ================================================================== [ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0 [ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7 ... [ 95.890755] Workqueue: events sco_sock_timeout [ 95.890755] Call Trace: [ 95.890755] [ 95.890755] dump_stack_lvl+0x45/0x110 [ 95.890755] print_address_description+0x78/0x390 [ 95.890755] print_report+0x11b/0x250 [ 95.890755] ? __virt_addr_valid+0xbe/0xf0 [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0 [ 95.890755] kasan_report+0x139/0x170 [ 95.890755] ? update_load_avg+0xe5/0x9f0 [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0 [ 95.890755] kasan_check_range+0x2c3/0x2e0 [ 95.890755] sco_sock_timeout+0x5e/0x1c0 [ 95.890755] process_one_work+0x561/0xc50 [ 95.890755] worker_thread+0xab2/0x13c0 [ 95.890755] ? pr_cont_work+0x490/0x490 [ 95.890755] kthread+0x279/0x300 [ 95.890755] ? pr_cont_work+0x490/0x490 [ 95.890755] ? kthread_blkcg+0xa0/0xa0 [ 95.890755] ret_from_fork+0x34/0x60 [ 95.890755] ? kthread_blkcg+0xa0/0xa0 [ 95.890755] ret_from_fork_asm+0x11/0x20 [ 95.890755] [ 95.890755] [ 95.890755] Allocated by task 506: [ 95.890755] kasan_save_track+0x3f/0x70 [ 95.890755] __kasan_kmalloc+0x86/0x90 [ 95.890755] __kmalloc+0x17f/0x360 [ 95.890755] sk_prot_alloc+0xe1/0x1a0 [ 95.890755] sk_alloc+0x31/0x4e0 [ 95.890755] bt_sock_alloc+0x2b/0x2a0 [ 95.890755] sco_sock_create+0xad/0x320 [ 95.890755] bt_sock_create+0x145/0x320 [ 95.890755] __sock_create+0x2e1/0x650 [ 95.890755] __sys_socket+0xd0/0x280 [ 95.890755] __x64_sys_socket+0x75/0x80 [ 95.890755] do_syscall_64+0xc4/0x1b0 [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 95.890755] [ 95.890755] Freed by task 506: [ 95.890755] kasan_save_track+0x3f/0x70 [ 95.890755] kasan_save_free_info+0x40/0x50 [ 95.890755] poison_slab_object+0x118/0x180 [ 95.890755] __kasan_slab_free+0x12/0x30 [ 95.890755] kfree+0xb2/0x240 [ 95.890755] __sk_destruct+0x317/0x410 [ 95.890755] sco_sock_release+0x232/0x280 [ 95.890755] sock_close+0xb2/0x210 [ 95.890755] __fput+0x37f/0x770 [ 95.890755] task_work_run+0x1ae/0x210 [ 95.890755] get_signal+0xe17/0xf70 [ 95.890755] arch_do_signal_or_restart+0x3f/0x520 [ 95.890755] syscall_exit_to_user_mode+0x55/0x120 [ 95.890755] do_syscall_64+0xd1/0x1b0 [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 95.890755] [ 95.890755] The buggy address belongs to the object at ffff88800c388000 [ 95.890755] which belongs to the cache kmalloc-1k of size 1024 [ 95.890755] The buggy address is located 128 bytes inside of [ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400) [ 95.890755] [ 95.890755] The buggy address belongs to the physical page: [ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388 [ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 95.890755] ano ---truncated---

Published: 2024-05-14Modified: 2026-01-22
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27399
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout There is a race condition between l2cap_chan_timeout() and l2cap_chan_del(). When we use l2cap_chan_del() to delete the channel, the chan->conn will be set to null. But the conn could be dereferenced again in the mutex_lock() of l2cap_chan_timeout(). As a result the null pointer dereference bug will happen. The KASAN report triggered by POC is shown below: [ 472.074580] ================================================================== [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0 [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7 [ 472.075308] [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.075308] Workqueue: events l2cap_chan_timeout [ 472.075308] Call Trace: [ 472.075308] [ 472.075308] dump_stack_lvl+0x137/0x1a0 [ 472.075308] print_report+0x101/0x250 [ 472.075308] ? __virt_addr_valid+0x77/0x160 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_report+0x139/0x170 [ 472.075308] ? mutex_lock+0x68/0xc0 [ 472.075308] kasan_check_range+0x2c3/0x2e0 [ 472.075308] mutex_lock+0x68/0xc0 [ 472.075308] l2cap_chan_timeout+0x181/0x300 [ 472.075308] process_one_work+0x5d2/0xe00 [ 472.075308] worker_thread+0xe1d/0x1660 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] kthread+0x2b7/0x350 [ 472.075308] ? pr_cont_work+0x5e0/0x5e0 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork+0x4d/0x80 [ 472.075308] ? kthread_blkcg+0xd0/0xd0 [ 472.075308] ret_from_fork_asm+0x11/0x20 [ 472.075308] [ 472.075308] ================================================================== [ 472.094860] Disabling lock debugging due to kernel taint [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 472.096136] #PF: supervisor write access in kernel mode [ 472.096136] #PF: error_code(0x0002) - not-present page [ 472.096136] PGD 0 P4D 0 [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36 [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4 [ 472.096136] Workqueue: events l2cap_chan_timeout [ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0 [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88 [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246 [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865 [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78 [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000 [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00 [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000 [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0 [ 472.096136] Call Trace: [ 472.096136] [ 472.096136] ? __die_body+0x8d/0xe0 [ 472.096136] ? page_fault_oops+0x6b8/0x9a0 [ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0 [ 472.096136] ? do_user_addr_fault+0x1027/0x1340 [ 472.096136] ? _printk+0x7a/0xa0 [ 472.096136] ? mutex_lock+0x68/0xc0 [ 472.096136] ? add_taint+0x42/0xd0 [ 472.096136] ? exc_page_fault+0x6a/0x1b0 [ 472.096136] ? asm_exc_page_fault+0x26/0x30 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] ? mutex_lock+0x88/0xc0 [ 472.096136] ? mutex_lock+0x75/0xc0 [ 472.096136] l2cap_chan_timeo ---truncated---

Published: 2024-05-14Modified: 2026-01-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27400
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2 This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap. The basic problem here is that after the move the old location is simply not available any more. Some fixes were suggested, but essentially we should call the move notification before actually moving things because only this way we have the correct order for DMA-buf and VM move notifications as well. Also rework the statistic handling so that we don't update the eviction counter before the move. v2: add missing NULL check

Published: 2024-05-14Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27401
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: firewire: nosy: ensure user_length is taken into account when fetching packet contents Ensure that packet_buffer_get respects the user_length provided. If the length of the head packet exceeds the user_length, packet_buffer_get will now return 0 to signify to the user that no data were read and a larger buffer size is required. Helps prevent user space overflows.

Published: 2024-05-14Modified: 2026-01-22
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-27402
MEDIUM5.8

In the Linux kernel, the following vulnerability has been resolved: phonet/pep: fix racy skb_queue_empty() use The receive queues are protected by their respective spin-lock, not the socket lock. This could lead to skb_peek() unexpectedly returning NULL or a pointer to an already dequeued socket buffer.

Published: 2024-05-17Modified: 2025-09-18
CVSS 3.xMEDIUM 5.8
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
References
CVE-2024-27403
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_flow_offload: reset dst in route object after setting up flow dst is transferred to the flow object, route object does not own it anymore. Reset dst in route object, otherwise if flow_offload_add() fails, error path releases dst twice, leading to a refcount underflow.

Published: 2024-05-17Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27404
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data races on remote_id Similar to the previous patch, address the data race on remote_id, adding the suitable ONCE annotations.

Published: 2024-05-17Modified: 2025-09-18
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27405
HIGH7.5

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize.

Published: 2024-05-17Modified: 2025-04-08
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27407
HIGH8.4

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr()

Published: 2024-05-17Modified: 2025-11-03
CVSS 3.xHIGH 8.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-27408
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup The Linked list element and pointer are not stored in the same memory as the eDMA controller register. If the doorbell register is toggled before the full write of the linked list a race condition error will occur. In remote setup we can only use a readl to the memory to assure the full write has occurred.

Published: 2024-05-17Modified: 2025-09-18
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27410
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject iftype change with mesh ID change It's currently possible to change the mesh ID when the interface isn't yet in mesh mode, at the same time as changing it into mesh mode. This leads to an overwrite of data in the wdev->u union for the interface type it currently has, causing cfg80211_change_iface() to do wrong things when switching. We could probably allow setting an interface to mesh while setting the mesh ID at the same time by doing a different order of operations here, but realistically there's no userspace that's going to do this, so just disallow changes in iftype when setting mesh ID.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27412
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: power: supply: bq27xxx-i2c: Do not free non existing IRQ The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxx_battery_i2c_probe() already has an if (client->irq) check wrapping the request_threaded_irq(). But bq27xxx_battery_i2c_remove() unconditionally calls free_irq(client->irq) leading to: [ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 free_irq+0x1b8/0x310 Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxx_battery_i2c_remove() mirroring probe() to fix this.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27413
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: efi/capsule-loader: fix incorrect allocation size gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit phys_addr_t: drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Use the correct type instead here.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27414
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back In the commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink checks IFLA_BRIDGE_MODE length"), an adjustment was made to the old loop logic in the function `rtnl_bridge_setlink` to enable the loop to also check the length of the IFLA_BRIDGE_MODE attribute. However, this adjustment removed the `break` statement and led to an error logic of the flags writing back at the end of this function. if (have_flags) memcpy(nla_data(attr), &flags, sizeof(flags)); // attr should point to IFLA_BRIDGE_FLAGS NLA !!! Before the mentioned commit, the `attr` is granted to be IFLA_BRIDGE_FLAGS. However, this is not necessarily true fow now as the updated loop will let the attr point to the last NLA, even an invalid NLA which could cause overflow writes. This patch introduces a new variable `br_flag` to save the NLA pointer that points to IFLA_BRIDGE_FLAGS and uses it to resolve the mentioned error logic.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27415
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: confirm multicast packets before passing them up the stack conntrack nf_confirm logic cannot handle cloned skbs referencing the same nf_conn entry, which will happen for multicast (broadcast) frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices. The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb. The Macvlan broadcast worker and normal confirm path will race. This race will not happen if step 2 already confirmed a clone. In that case later steps perform skb_clone() with skb->_nfct already confirmed (in hash table). This works fine. But such confirmation won't happen when eb/ip/nftables rules dropped the packets before they reached the nf_confirm step in postrouting. Pablo points out that nf_conntrack_bridge doesn't allow use of stateful nat, so we can safely discard the nf_conn entry and let inet call conntrack again. This doesn't work for bridge netfilter: skb could have a nat transformation. Also bridge nf prevents re-invocation of inet prerouting via 'sabotage_in' hook. Work around this problem by explicit confirmation of the entry at LOCAL_IN time, before upper layer has a chance to clone the unconfirmed entry. The downside is that this disables NAT and conntrack helpers. Alternative fix would be to add locking to all code parts that deal with unconfirmed packets, but even if that could be done in a sane way this opens up other problems, for example: -m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5 For multicast case, only one of such conflicting mappings will be created, conntrack only handles 1:1 NAT mappings. Users should set create a setup that explicitly marks such traffic NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass them, ruleset might have accept rules for untracked traffic already, so user-visible behaviour would change.

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27416
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27417
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix potential "struct net" leak in inet6_rtm_getaddr() It seems that if userspace provides a correct IFA_TARGET_NETNSID value but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() returns -EINVAL with an elevated "struct net" refcount.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27418
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: mctp: take ownership of skb in mctp_local_output Currently, mctp_local_output only takes ownership of skb on success, and we may leak an skb if mctp_local_output fails in specific states; the skb ownership isn't transferred until the actual output routing occurs. Instead, make mctp_local_output free the skb on all error paths up to the route action, so it always consumes the passed skb.

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27419
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: netrom: Fix data-races around sysctl_net_busy_read We need to protect the reader reading the sysctl value because the value can be changed concurrently.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27431
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cpumap: Zero-initialise xdp_rxq_info struct before running XDP program When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27432
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: fix PPE hanging issue A patch to resolve an issue was found in MediaTek's GPL-licensed SDK: In the mtk_ppe_stop() function, the PPE scan mode is not disabled before disabling the PPE. This can potentially lead to a hang during the process of disabling the PPE. Without this patch, the PPE may experience a hang during the reboot test.

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27435
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nvme: fix reconnection fail due to reserved tag allocation We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue.

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27436
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Stop parsing channels bits when all channels are found. If a usb audio device sets more bits than the amount of channels it could write outside of the map array.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-27437
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required.

Published: 2024-04-05Modified: 2025-03-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-31076
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU. When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU. Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors. However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU. In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->prev_vector to 0. As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak. To address this issue, move the invocation of irq_force_complete_move() before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the interrupt is currently or used to be affine to the outgoing CPU. Additionally, reclaim the vector in __vector_schedule_cleanup() as well, following a warning message, although theoretically it should never see apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-33619
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: efi: libstub: only free priv.runtime_map when allocated priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.

Published: 2024-06-21Modified: 2025-03-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-33621
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path. WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043) The warning triggers as this: packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKET Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-33847
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: don't allow unaligned truncation on released compress inode f2fs image may be corrupted after below testcase: - mkfs.f2fs -O extra_attr,compression -f /dev/vdb - mount /dev/vdb /mnt/f2fs - touch /mnt/f2fs/file - f2fs_io setflags compression /mnt/f2fs/file - dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4 - f2fs_io release_cblocks /mnt/f2fs/file - truncate -s 8192 /mnt/f2fs/file - umount /mnt/f2fs - fsck.f2fs /dev/vdb [ASSERT] (fsck_chk_inode_blk:1256) --> ino: 0x5 has i_blocks: 0x00000002, but has 0x3 blocks [FSCK] valid_block_count matching with CP [Fail] [0x4, 0x5] [FSCK] other corrupted bugs [Fail] The reason is: partial truncation assume compressed inode has reserved blocks, after partial truncation, valid block count may change w/o .i_blocks and .total_valid_block_count update, result in corruption. This patch only allow cluster size aligned truncation on released compress inode for fixing.

Published: 2024-06-24Modified: 2025-10-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-34027
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case.

Published: 2024-06-24Modified: 2025-03-24
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-34777
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: fix node id validation While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to: BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node. Found by Linux Verification Center (linuxtesting.org).

Published: 2024-06-21Modified: 2025-09-17
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35247
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fpga: region: add owner module and take its refcount The current implementation of the fpga region assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the region during programming if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_region struct and use it to take the module's refcount. Modify the functions for registering a region to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the region as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a region without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga region.

Published: 2024-06-24Modified: 2025-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35784
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase.

Published: 2024-05-17Modified: 2025-01-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35785
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: tee: optee: Fix kernel panic caused by incorrect error handling The error path while failing to register devices on the TEE bus has a bug leading to kernel panic as follows: [ 15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c [ 15.406913] Mem abort info: [ 15.409722] ESR = 0x0000000096000005 [ 15.413490] EC = 0x25: DABT (current EL), IL = 32 bits [ 15.418814] SET = 0, FnV = 0 [ 15.421878] EA = 0, S1PTW = 0 [ 15.425031] FSC = 0x05: level 1 translation fault [ 15.429922] Data abort info: [ 15.432813] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 15.438310] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 15.443372] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000 [ 15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000 [ 15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration") lead to the introduction of this bug. So fix it appropriately.

Published: 2024-05-17Modified: 2026-01-22
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35789
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35790
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI.

Published: 2024-05-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35791
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() Do the cache flush of converted pages in svm_register_enc_region() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has __unregister_enc_region_locked() already queued up for the region. Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed. Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35796
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: ll_temac: platform_get_resource replaced by wrong function The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name. This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name)) It should have been replaced with devm_platform_ioremap_resource.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35799
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Prevent crash when disable stream [Why] Disabling stream encoder invokes a function that no longer exists. [How] Check if the function declaration is NULL in disable stream encoder.

Published: 2024-05-17Modified: 2025-09-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35801
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD Commit 672365477ae8 ("x86/fpu: Update XFD state where required") and commit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced a per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in order to avoid unnecessary writes to the MSR. On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which wipes out any stale state. But the per CPU cached xfd value is not reset, which brings them out of sync. As a consequence a subsequent xfd_update_state() might fail to update the MSR which in turn can result in XRSTOR raising a #NM in kernel space, which crashes the kernel. To fix this, introduce xfd_set_state() to write xfd_state together with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.

Published: 2024-05-17Modified: 2025-09-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35803
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made.

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35804
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Mark target gfn of emulated atomic instruction as dirty When emulating an atomic access on behalf of the guest, mark the target gfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. This fixes a bug where KVM effectively corrupts guest memory during live migration by writing to guest memory without informing userspace that the page is dirty. Marking the page dirty got unintentionally dropped when KVM's emulated CMPXCHG was converted to do a user access. Before that, KVM explicitly mapped the guest page into kernel memory, and marked the page dirty during the unmap phase. Mark the page dirty even if the CMPXCHG fails, as the old data is written back on failure, i.e. the page is still written. The value written is guaranteed to be the same because the operation is atomic, but KVM's ABI is that all writes are dirty logged regardless of the value written. And more importantly, that's what KVM did before the buggy commit. Huge kudos to the folks on the Cc list (and many others), who did all the actual work of triaging and debugging. base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

Published: 2024-05-17Modified: 2025-09-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35805
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dm snapshot: fix lockup in dm_exception_table_exit There was reported lockup when we exit a snapshot with many exceptions. Fix this by adding "cond_resched" to the loop that frees the exceptions.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35806
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Always disable interrupts when taking cgr_lock smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers.

Published: 2024-05-17Modified: 2025-01-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35807
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: fix corruption during on-line resize We observed a corruption during on-line resize of a file system that is larger than 16 TiB with 4k block size. With having more then 2^32 blocks resize_inode is turned off by default by mke2fs. The issue can be reproduced on a smaller file system for convenience by explicitly turning off resize_inode. An on-line resize across an 8 GiB boundary (the size of a meta block group in this setup) then leads to a corruption: dev=/dev/ # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per block group and 2^6 are the number of block groups that make a meta block group. The last checksum might be different depending on how the file is laid out across the physical blocks. The actual corruption occurs at physical block 63*2^15 = 2064384 which would be the location of the backup of the meta block group's block descriptor. During the on-line resize the file system will be converted to meta_bg starting at s_first_meta_bg which is 2 in the example - meaning all block groups after 16 GiB. However, in ext4_flex_group_add we might add block groups that are not part of the first meta block group yet. In the reproducer we achieved this by substracting the size of a whole block group from the point where the meta block group would start. This must be considered when updating the backup block group descriptors to follow the non-meta_bg layout. The fix is to add a test whether the group to add is already part of the meta block group or not.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35809
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: PCI/PM: Drain runtime-idle callbacks before driver removal A race condition between the .runtime_idle() callback and the .remove() callback in the rtsx_pcr PCI driver leads to a kernel crash due to an unhandled page fault [1]. The problem is that rtsx_pci_runtime_idle() is not expected to be running after pm_runtime_get_sync() has been called, but the latter doesn't really guarantee that. It only guarantees that the suspend and resume callbacks will not be running when it returns. However, if a .runtime_idle() callback is already running when pm_runtime_get_sync() is called, the latter will notice that the runtime PM status of the device is RPM_ACTIVE and it will return right away without waiting for the former to complete. In fact, it cannot wait for .runtime_idle() to complete because it may be called from that callback (it arguably does not make much sense to do that, but it is not strictly prohibited). Thus in general, whoever is providing a .runtime_idle() callback needs to protect it from running in parallel with whatever code runs after pm_runtime_get_sync(). [Note that .runtime_idle() will not start after pm_runtime_get_sync() has returned, but it may continue running then if it has started earlier.] One way to address that race condition is to call pm_runtime_barrier() after pm_runtime_get_sync() (not before it, because a nonzero value of the runtime PM usage counter is necessary to prevent runtime PM callbacks from being invoked) to wait for the .runtime_idle() callback to complete should it be running at that point. A suitable place for doing that is in pci_device_remove() which calls pm_runtime_get_sync() before removing the driver, so it may as well call pm_runtime_barrier() subsequently, which will prevent the race in question from occurring, not just in the rtsx_pcr driver, but in any PCI drivers providing .runtime_idle() callbacks.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35811
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]

Published: 2024-05-17Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35813
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mmc: core: Avoid negative index with array access Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns prev_idata = idatas[i - 1], but doesn't check that the iterator i is greater than zero. Let's fix this by adding a check.

Published: 2024-05-17Modified: 2025-12-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35817
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue.

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35818
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). And we no longer need to override queued_spin_unlock() so use the generic definition. Without this, we get such an error when run 'glxgears' on weak ordering architectures such as LoongArch: radeon 0000:04:00.0: ring 0 stalled for more than 10324msec radeon 0000:04:00.0: ring 3 stalled for more than 10240msec radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3) radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35) radeon 0000:04:00.0: scheduling IB failed (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35819
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Use raw spinlock for cgr_lock smp_call_function always runs its callback in hard IRQ context, even on PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock for cgr_lock to ensure we aren't waiting on a sleeping task. Although this bug has existed for a while, it was not apparent until commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change") which invokes smp_call_function_single via qman_update_cgr_safe every time a link goes up or down.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35821
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ubifs: Set page uptodate in the correct place Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35822
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep It is possible trigger below warning message from mass storage function, WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35823
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: vt: fix unicode buffer corruption when deleting characters This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers.

Published: 2024-05-17Modified: 2025-04-07
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-35824
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: misc: lis3lv02d_i2c: Fix regulators getting en-/dis-abled twice on suspend/resume When not configured for wakeup lis3lv02d_i2c_suspend() will call lis3lv02d_poweroff() even if the device has already been turned off by the runtime-suspend handler and if configured for wakeup and the device is runtime-suspended at this point then it is not turned back on to serve as a wakeup source. Before commit b1b9f7a49440 ("misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback"), lis3lv02d_poweroff() failed to disable the regulators which as a side effect made calling poweroff() twice ok. Now that poweroff() correctly disables the regulators, doing this twice triggers a WARN() in the regulator core: unbalanced disables for regulator-dummy WARNING: CPU: 1 PID: 92 at drivers/regulator/core.c:2999 _regulator_disable ... Fix lis3lv02d_i2c_suspend() to not call poweroff() a second time if already runtime-suspended and add a poweron() call when necessary to make wakeup work. lis3lv02d_i2c_resume() has similar issues, with an added weirness that it always powers on the device if it is runtime suspended, after which the first runtime-resume will call poweron() again, causing the enabled count for the regulator to increase by 1 every suspend/resume. These unbalanced regulator_enable() calls cause the regulator to never be turned off and trigger the following WARN() on driver unbind: WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put Fix this by making lis3lv02d_i2c_resume() mirror the new suspend().

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35825
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Fix handling of zero block length packets While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present. According to the NCM spec: "If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent. wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues. wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB" However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35826
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: block: Fix page refcounts for unaligned buffers in __bio_release_pages() Fix an incorrect number of pages being released for buffers that do not start at the beginning of a page.

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35827
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: io_uring/net: fix overflow check in io_recvmsg_mshot_prep() The "controllen" variable is type size_t (unsigned long). Casting it to int could lead to an integer underflow. The check_add_overflow() function considers the type of the destination which is type int. If we add two positive values and the result cannot fit in an integer then that's counted as an overflow. However, if we cast "controllen" to an int and it turns negative, then negative values *can* fit into an int type so there is no overflow. Good: 100 + (unsigned long)-4 = 96 <-- overflow Bad: 100 + (int)-4 = 96 <-- no overflow I deleted the cast of the sizeof() as well. That's not a bug but the cast is unnecessary.

Published: 2024-05-17Modified: 2025-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35828
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().

Published: 2024-05-17Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35829
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix a memleak in lima_heap_alloc When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks.

Published: 2024-05-17Modified: 2025-04-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35830
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: tc358743: register v4l2 async device only after successful setup Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access.

Published: 2024-05-17Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35833
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA This dma_alloc_coherent() is undone neither in the remove function, nor in the error handling path of fsl_qdma_probe(). Switch to the managed version to fix both issues.

Published: 2024-05-17Modified: 2025-04-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35844
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix reserve_cblocks counting error when out of space When a file only needs one direct_node, performing the following operations will cause the file to be unrepairable: unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data unisoc # ./f2fs_io release_cblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4.8M 100% /data unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 0 This is because the file has only one direct_node. After returning to -ENOSPC, reserved_blocks += ret will not be executed. As a result, the reserved_blocks at this time is still 0, which is not the real number of reserved blocks. Therefore, fsck cannot be set to repair the file. After this patch, the fsck flag will be set to fix this problem. unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device adb reboot then fsck will be executed unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 924

Published: 2024-05-17Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35845
CRITICAL9.1

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dbg-tlv: ensure NUL termination The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated correctly before using it.

Published: 2024-05-17Modified: 2025-04-07
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35847
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ]

Published: 2024-05-17Modified: 2024-12-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35848
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: eeprom: at24: fix memory corruption race condition If the eeprom is not accessible, an nvmem device will be registered, the read will fail, and the device will be torn down. If another driver accesses the nvmem device after the teardown, it will reference invalid memory. Move the failure point before registering the nvmem device.

Published: 2024-05-17Modified: 2025-12-23
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35849
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix information leak in btrfs_ioctl_logical_to_ino() Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000 This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory. Fix this by using kvzalloc() which zeroes out the memory on allocation.

Published: 2024-05-17Modified: 2025-02-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35851
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NULL-deref on non-serdev suspend Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend. Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup() time.

Published: 2024-05-17Modified: 2024-12-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35852
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work The rehash delayed work is rescheduled with a delay if the number of credits at end of the work is not negative as supposedly it means that the migration ended. Otherwise, it is rescheduled immediately. After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash" the above is no longer accurate as a non-negative number of credits is no longer indicative of the migration being done. It can also happen if the work encountered an error in which case the migration will resume the next time the work is scheduled. The significance of the above is that it is possible for the work to be pending and associated with hints that were allocated when the migration started. This leads to the hints being leaked [1] when the work is canceled while pending as part of ACL region dismantle. Fix by freeing the hints if hints are associated with a work that was canceled while pending. Blame the original commit since the reliance on not having a pending work associated with hints is fragile. [1] unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] process_one_work+0x59c/0xf20 [<00000000ceee9e81>] worker_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30

Published: 2024-05-17Modified: 2024-12-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35853
MEDIUM6.4

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak during rehash The rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters. If the migration fails, the code tries to migrate the filters back to the old region. However, the rollback itself can also fail in which case another migration will be erroneously performed. Besides the fact that this ping pong is not a very good idea, it also creates a problem. Each virtual chunk references two chunks: The currently used one ('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the first holds the chunk we want to migrate filters to and the second holds the chunk we are migrating filters from. The code currently assumes - but does not verify - that the backup chunk does not exist (NULL) if the currently used chunk does not reference the target region. This assumption breaks when we are trying to rollback a rollback, resulting in the backup chunk being overwritten and leaked [1]. Fix by not rolling back a failed rollback and add a warning to avoid future cases. [1] WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20 Modules linked in: CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:parman_destroy+0x17/0x20 [...] Call Trace: mlxsw_sp_acl_atcam_region_fini+0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30

Published: 2024-05-17Modified: 2025-04-07
CVSS 3.xMEDIUM 6.4
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
References
CVE-2024-35854
HIGH8.8

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash The rehash delayed work migrates filters from one region to another according to the number of available credits. The migrated from region is destroyed at the end of the work if the number of credits is non-negative as the assumption is that this is indicative of migration being complete. This assumption is incorrect as a non-negative number of credits can also be the result of a failed migration. The destruction of a region that still has filters referencing it can result in a use-after-free [1]. Fix by not destroying the region if migration failed. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858 CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work Call Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

Published: 2024-05-17Modified: 2025-04-07
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35855
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update The rule activity update delayed work periodically traverses the list of configured rules and queries their activity from the device. As part of this task it accesses the entry pointed by 'ventry->entry', but this entry can be changed concurrently by the rehash delayed work, leading to a use-after-free [1]. Fix by closing the race and perform the activity query under the 'vregion->lock' mutex. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181 CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work Call Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

Published: 2024-05-17Modified: 2024-12-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35857
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: icmp: prevent possible NULL dereferences from icmp_build_probe() First problem is a double call to __in_dev_get_rcu(), because the second one could return NULL. if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list) Second problem is a read from dev->ip6_ptr with no NULL check: if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list)) Use the correct RCU API to fix these. v2: add missing include

Published: 2024-05-17Modified: 2025-04-07
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-35860
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: support deferring bpf_link dealloc to after RCU grace period BPF link for some program types is passed as a "context" which can be used by those BPF programs to look up additional information. E.g., for multi-kprobes and multi-uprobes, link is used to fetch BPF cookie values. Because of this runtime dependency, when bpf_link refcnt drops to zero there could still be active BPF programs running accessing link data. This patch adds generic support to defer bpf_link dealloc callback to after RCU GP, if requested. This is done by exposing two different deallocation callbacks, one synchronous and one deferred. If deferred one is provided, bpf_link_free() will schedule dealloc_deferred() callback to happen after RCU GP. BPF is using two flavors of RCU: "classic" non-sleepable one and RCU tasks trace one. The latter is used when sleepable BPF programs are used. bpf_link_free() accommodates that by checking underlying BPF program's sleepable flag, and goes either through normal RCU GP only for non-sleepable, or through RCU tasks trace GP *and* then normal RCU GP (taking into account rcu_trace_implies_rcu_gp() optimization), if BPF program is sleepable. We use this for multi-kprobe and multi-uprobe links, which dereference link during program run. We also preventively switch raw_tp link to use deferred dealloc callback, as upcoming changes in bpf-next tree expose raw_tp link data (specifically, cookie value) to BPF program at runtime as well.

Published: 2024-05-19Modified: 2025-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35861
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_signal_cifsd_for_reconnect() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-05-19Modified: 2026-03-24
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35862
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_network_name_deleted() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-05-19Modified: 2026-03-25
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35863
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-05-19Modified: 2026-03-24
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35864
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35865
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-05-19Modified: 2025-04-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35866
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_dump_full_key() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-05-19Modified: 2026-04-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35867
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-05-19Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35868
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_write() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF.

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35870
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in smb2_reconnect_server() The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING. To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down. The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc: kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Published: 2024-05-19Modified: 2025-11-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-35871
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: riscv: process: Fix kernel gp leakage childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switch_to. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means. [From the email thread] The /* Kernel thread */ comment is somewhat inaccurate in that it is also used for user_mode_helper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/core_pattern is a pipe. Such threads do not have PF_KTHREAD set and are valid targets for ptrace etc. even before they exec. childregs is the *user* context during syscall execution and it is observable from userspace in at least five ways: 1. kernel_execve does not currently clear integer registers, so the starting register state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel __global_pointer$, all other integer registers zeroed by the memset in the patch comment. This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch. 2. ptrace(PTRACE_GETREGSET): you can PTRACE_ATTACH to a user_mode_helper thread before it execs, but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries. 3. /proc/*/task/*/syscall: this is perfectly happy to read pt_regs for user_mode_helpers before the exec completes, but gp is not one of the registers it returns. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normally prevents access to kernel addresses via PERF_SAMPLE_REGS_INTR, but due to this bug kernel addresses are also exposed via PERF_SAMPLE_REGS_USER which is permitted under LOCKDOWN_PERF. I have not attempted to write exploit code. 5. Much of the tracing infrastructure allows access to user registers. I have not attempted to determine which forms of tracing allow access to user registers without already allowing access to kernel registers.

Published: 2024-05-19Modified: 2026-01-22
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35872
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix GUP-fast succeeding on secretmem folios folio_is_secretmem() currently relies on secretmem folios being LRU folios, to save some cycles. However, folios might reside in a folio batch without the LRU flag set, or temporarily have their LRU flag cleared. Consequently, the LRU flag is unreliable for this purpose. In particular, this is the case when secretmem_fault() allocates a fresh page and calls filemap_add_folio()->folio_add_lru(). The folio might be added to the per-cpu folio batch and won't get the LRU flag set until the batch was drained using e.g., lru_add_drain(). Consequently, folio_is_secretmem() might not detect secretmem folios and GUP-fast can succeed in grabbing a secretmem folio, crashing the kernel when we would later try reading/writing to the folio, because the folio has been unmapped from the directmap. Fix it by removing that unreliable check.

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35875
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/coco: Require seeding RNG with RDRAND on CoCo systems There are few uses of CoCo that don't rely on working cryptography and hence a working RNG. Unfortunately, the CoCo threat model means that the VM host cannot be trusted and may actively work against guests to extract secrets or manipulate computation. Since a malicious host can modify or observe nearly all inputs to guests, the only remaining source of entropy for CoCo guests is RDRAND. If RDRAND is broken -- due to CPU hardware fault -- the RNG as a whole is meant to gracefully continue on gathering entropy from other sources, but since there aren't other sources on CoCo, this is catastrophic. This is mostly a concern at boot time when initially seeding the RNG, as after that the consequences of a broken RDRAND are much more theoretical. So, try at boot to seed the RNG using 256 bits of RDRAND output. If this fails, panic(). This will also trigger if the system is booted without RDRAND, as RDRAND is essential for a safe CoCo boot. Add this deliberately to be "just a CoCo x86 driver feature" and not part of the RNG itself. Many device drivers and platforms have some desire to contribute something to the RNG, and add_device_randomness() is specifically meant for this purpose. Any driver can call it with seed data of any quality, or even garbage quality, and it can only possibly make the quality of the RNG better or have no effect, but can never make it worse. Rather than trying to build something into the core of the RNG, consider the particular CoCo issue just a CoCo issue, and therefore separate it all out into driver (well, arch/platform) code. [ bp: Massage commit message. ]

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35877
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size. For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios. Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn(): <--- C reproducer ---> #include #include #include #include int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; } <--- C reproducer ---> On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] [ 301.566325] ? untrack_pfn+0xf4/0x100 [ 301.566618] ? __warn+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 3 ---truncated---

Published: 2024-05-19Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35878
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: of: module: prevent NULL pointer dereference in vsnprintf() In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.

Published: 2024-05-19Modified: 2025-04-07
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-35879
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: of: dynamic: Synchronize of_changeset_destroy() with the devlink removals In the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but __of_changeset_entry_destroy() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached of_node) is done by a job queued in a workqueue and so, it is done asynchronously with respect to function calls. When the warning is present, of_node_put() will be called but wrongly too late from the workqueue job. In order to be sure that any ongoing devlink removals are done before the of_node destruction, synchronize the of_changeset_destroy() with the devlink removals.

Published: 2024-05-19Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35884
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: udp: do not accept non-tunnel GSO skbs landing in a tunnel When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. The same thing can happen with rx-gro-list. We saw this with geneve packets being GROed at the UDP level. In such case gso_size is set; later the packet goes through the geneve rx path, the geneve header is pulled, the offset are adjusted and frag_list skbs are not adjusted with regard to geneve. When those skbs hit skb_fragment, it will misbehave. Different outcomes are possible depending on what the GROed skbs look like; from corrupted packets to kernel crashes. One example is a BUG_ON[1] triggered in skb_segment while processing the frag_list. Because gso_size is wrong (geneve header was pulled) skb_segment thinks there is "geneve header size" of data in frag_list, although it's in fact the next packet. The BUG_ON itself has nothing to do with the issue. This is only one of the potential issues. Looking up for a matching socket in udp_gro_receive is fragile: the lookup could be extended to all netns (not speaking about performances) but nothing prevents those packets from being modified in between and we could still not find a matching socket. It's OK to keep the current logic there as it should cover most cases but we also need to make sure we handle tunnel packets being GROed too early. This is done by extending the checks in udp_unexpected_gso: GSO packets lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must be segmented. [1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560

Published: 2024-05-19Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35885
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: stop interface during shutdown The mlxbf_gige driver intermittantly encounters a NULL pointer exception while the system is shutting down via "reboot" command. The mlxbf_driver will experience an exception right after executing its shutdown() method. One example of this exception is: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000 [0000000000000070] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] SMP CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] sp : ffff8000080d3c10 x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58 x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008 x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128 x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7 x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101 x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404 x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080 x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 run_ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+0x10/0x20 Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002) ---[ end trace 7cc3941aa0d8e6a4 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x4ce722520000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x000005c1,a3330e5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- During system shutdown, the mlxbf_gige driver's shutdown() is always executed. However, the driver's stop() method will only execute if networking interface configuration logic within the Linux distribution has been setup to do so. If shutdown() executes but stop() does not execute, NAPI remains enabled and this can lead to an exception if NAPI is scheduled while the hardware interface has only been partially deinitialized. The networking interface managed by the mlxbf_gige driver must be properly stopped during system shutdown so that IFF_UP is cleared, the hardware interface is put into a clean state, and NAPI is fully deinitialized.

Published: 2024-05-19Modified: 2025-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35886
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix infinite recursion in fib6_dump_done(). syzkaller reported infinite recursive calls of fib6_dump_done() during netlink socket destruction. [1] From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then the response was generated. The following recvmmsg() resumed the dump for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due to the fault injection. [0] 12:01:34 executing program 3: r0 = socket$nl_route(0x10, 0x3, 0x0) sendmsg$nl_route(r0, ... snip ...) recvmmsg(r0, ... snip ...) (fail_nth: 8) Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3]. syzkaller stopped receiving the response halfway through, and finally netlink_sock_destruct() called nlk_sk(sk)->cb.done(). fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it is still not NULL. fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling itself recursively and hitting the stack guard page. To avoid the issue, let's set the destructor after kzalloc(). [0]: FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:117) should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153) should_failslab (mm/slub.c:3733) kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992) inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662) rtnl_dump_all (net/core/rtnetlink.c:4029) netlink_dump (net/netlink/af_netlink.c:2269) netlink_recvmsg (net/netlink/af_netlink.c:1988) ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801) ___sys_recvmsg (net/socket.c:2846) do_recvmmsg (net/socket.c:2943) __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034) [1]: BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb) stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570) Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d980000 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3 RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358 RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000 R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68 FS: 0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <#DF> fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) ... fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1)) netlink_sock_destruct (net/netlink/af_netlink.c:401) __sk_destruct (net/core/sock.c:2177 (discriminator 2)) sk_destruct (net/core/sock.c:2224) __sk_free (net/core/sock.c:2235) sk_free (net/core/sock.c:2246) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue. ---truncated---

Published: 2024-05-19Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35887
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer.

Published: 2024-05-19Modified: 2024-12-31
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35888
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: erspan: make sure erspan_base_hdr is present in skb->head syzbot reported a problem in ip6erspan_rcv() [1] Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it. Add the missing pskb_may_pull() calls. v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed. [1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0

Published: 2024-05-19Modified: 2025-04-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35890
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: gro: fix ownership transfer If packets are GROed with fraglist they might be segmented later on and continue their journey in the stack. In skb_segment_list those skbs can be reused as-is. This is an issue as their destructor was removed in skb_gro_receive_list but not the reference to their socket, and then they can't be orphaned. Fix this by also removing the reference to the socket. For example this could be observed, kernel BUG at include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Call Trace: ipv6_list_rcv+0x250/0x3f0 __netif_receive_skb_list_core+0x49d/0x8f0 netif_receive_skb_list_internal+0x634/0xd40 napi_complete_done+0x1d2/0x7d0 gro_cell_poll+0x118/0x1f0 A similar construction is found in skb_gro_receive, apply the same change there.

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35891
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Fix potential null pointer dereference In lan8814_get_sig_rx() and lan8814_get_sig_tx() ptp_parse_header() may return NULL as ptp_header due to abnormal packet type or corrupted packet. Fix this bug by adding ptp_header check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35892
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/sched: fix lockdep splat in qdisc_tree_reduce_backlog() qdisc_tree_reduce_backlog() is called with the qdisc lock held, not RTNL. We must use qdisc_lookup_rcu() instead of qdisc_lookup() syzbot reported: WARNING: suspicious RCU usage 6.1.74-syzkaller #0 Not tainted ----------------------------- net/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by udevd/1142: #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline] #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282 #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline] #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297 #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline] #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792 stack backtrace: CPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: [] __dump_stack lib/dump_stack.c:88 [inline] [] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106 [] dump_stack+0x15/0x1e lib/dump_stack.c:113 [] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592 [] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305 [] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811 [] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51 [] qdisc_enqueue include/net/sch_generic.h:833 [inline] [] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723 [] dequeue_skb net/sched/sch_generic.c:292 [inline] [] qdisc_restart net/sched/sch_generic.c:397 [inline] [] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415 [] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [] net_tx_action+0x7c9/0x970 net/core/dev.c:5313 [] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616 [] invoke_softirq kernel/softirq.c:447 [inline] [] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700 [] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712 [] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656

Published: 2024-05-19Modified: 2025-09-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35893
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_skbmod: prevent kernel-infoleak syzbot found that tcf_skbmod_dump() was copying four bytes from kernel stack to user space [1]. The issue here is that 'struct tc_skbmod' has a four bytes hole. We need to clear the structure before filling fields. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli ---truncated---

Published: 2024-05-19Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35895
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Prevent lock inversion deadlock in map delete elem syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable(); lock(&host->lock); lock(&htab->buckets[i].lock); lock(&host->lock); Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context. Detect when map_delete_elem operation is invoked from a context which is _not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an error. Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today.

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35896
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: netfilter: validate user input for expected length I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt") setsockopt() @optlen argument should be taken into account before copying data. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238 CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 Allocated by task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline] __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated---

Published: 2024-05-19Modified: 2025-03-21
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35897
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: discard table flag update with pending basechain deletion Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core.

Published: 2024-05-19Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35898
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process.

Published: 2024-05-19Modified: 2025-04-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35899
MEDIUM6.1

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: flush pending destroy work before exit_net release Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue. The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace: [ 1360.547991] [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [ 1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ? __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] [ 1360.548719] Allocated by task 192061: [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750] __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [ 1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953] ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 1360.548994] Freed by task 192222: [ 1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036] __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [ 1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d (gdb) list *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list); 11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354 list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356 nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat ---truncated---

Published: 2024-05-19Modified: 2025-04-07
CVSS 3.xMEDIUM 6.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H
References
CVE-2024-35900
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: reject new basechain after table flag update When dormant flag is toggled, hooks are disabled in the commit phase by iterating over current chains in table (existing and new). The following configuration allows for an inconsistent state: add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; } which triggers the following warning when trying to unregister chain w which is already unregistered. [ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260 [...] [ 127.322519] Call Trace: [ 127.322521] [ 127.322524] ? __warn+0x9f/0x1a0 [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322537] ? report_bug+0x1b1/0x1e0 [ 127.322545] ? handle_bug+0x3c/0x70 [ 127.322552] ? exc_invalid_op+0x17/0x40 [ 127.322556] ? asm_exc_invalid_op+0x1a/0x20 [ 127.322563] ? kasan_save_free_info+0x3b/0x60 [ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260 [ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260 [ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables] [ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables] [ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]

Published: 2024-05-19Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35904
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: selinux: avoid dereference of garbage after mount failure In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer. While on it drop the never read static variable selinuxfs_mount.

Published: 2024-05-19Modified: 2025-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35905
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bpf: Protect against int overflow for stack access size This patch re-introduces protection against the size of access to stack memory being negative; the access size can appear negative as a result of overflowing its signed int representation. This should not actually happen, as there are other protections along the way, but we should protect against it anyway. One code path was missing such protections (fixed in the previous patch in the series), causing out-of-bounds array accesses in check_stack_range_initialized(). This patch causes the verification of a program with such a non-sensical access size to fail. This check used to exist in a more indirect way, but was inadvertendly removed in a833a17aeac7.

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35907
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: call request_irq() after NAPI initialized The mlxbf_gige driver encounters a NULL pointer exception in mlxbf_gige_open() when kdump is enabled. The sequence to reproduce the exception is as follows: a) enable kdump b) trigger kdump via "echo c > /proc/sysrq-trigger" c) kdump kernel executes d) kdump kernel loads mlxbf_gige module e) the mlxbf_gige module runs its open() as the the "oob_net0" interface is brought up f) mlxbf_gige module will experience an exception during its open(), something like: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000086000004 [#1] SMP CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000 x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398 x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2 x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238 Call trace: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x20/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 [mlxbf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink+0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg+0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x54/0x184 do_el0_svc+0x30/0xac el0_svc+0x48/0x160 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Code: bad PC value ---[ end trace 7d1c3f3bf9d81885 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x2870a7a00000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0,000005c1,a3332a5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- The exception happens because there is a pending RX interrupt before the call to request_irq(RX IRQ) executes. Then, the RX IRQ handler fires immediately after this request_irq() completes. The ---truncated---

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35908
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tls: get psock ref after taking rxlock to avoid leak At the start of tls_sw_recvmsg, we take a reference on the psock, and then call tls_rx_reader_lock. If that fails, we return directly without releasing the reference. Instead of adding a new label, just take the reference after locking has succeeded, since we don't need it before.

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35909
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: wwan: t7xx: Split 64bit accesses to fix alignment issues Some of the registers are aligned on a 32bit boundary, causing alignment faults on 64bit platforms. Unable to handle kernel paging request at virtual address ffffffc084a1d004 Mem abort info: ESR = 0x0000000096000061 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alignment fault Data abort info: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Internal error: Oops: 0000000096000061 [#1] SMP Modules linked in: mtk_t7xx(+) qcserial pppoe ppp_async option nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) iwlwifi(O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm cdc_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 geniv des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys trusted CPU: 3 PID: 5266 Comm: kworker/u9:1 Tainted: G O 6.6.22 #0 Hardware name: Bananapi BPI-R4 (DT) Workqueue: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr : t7xx_cldma_start+0xac/0x13c [mtk_t7xx] sp : ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 0000000000000001 x19: ffffff80c814b080 x18: 0000000000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffffff80ca1ef6b4 x7 : ffffff80c814b818 x6 : 0000000000000018 x5 : 0000000000000870 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000010a947000 x1 : ffffffc084a1d004 x0 : ffffffc084a1d004 Call trace: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] process_one_work+0x154/0x2a0 worker_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Code: f9400800 91001000 8b214001 d50332bf (f9000022) ---[ end trace 0000000000000000 ]--- The inclusion of io-64-nonatomic-lo-hi.h indicates that all 64bit accesses can be replaced by pairs of nonatomic 32bit access. Fix alignment by forcing all accesses to be 32bit on 64bit platforms.

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35910
MEDIUM5.8

In the Linux kernel, the following vulnerability has been resolved: tcp: properly terminate timers for kernel sockets We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled. Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago. When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers. inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later. For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns. For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns. This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler. Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held. It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code) We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.

Published: 2024-05-19Modified: 2025-12-17
CVSS 3.xMEDIUM 5.8
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
References
CVE-2024-35912
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: rfi: fix potential response leaks If the rx payload length check fails, or if kmemdup() fails, we still need to free the command response. Fix that.

Published: 2024-05-19Modified: 2025-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35915
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet syzbot reported the following uninit-value access issue [1][2]: nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded. This patch resolved this issue by checking payload size before calling each message type handler codes.

Published: 2024-05-19Modified: 2025-02-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35916
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: dma-buf: Fix NULL pointer dereference in sanitycheck() If due to a memory allocation failure mock_chain() returns NULL, it is passed to dma_fence_enable_sw_signaling() resulting in NULL pointer dereference there. Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-05-19Modified: 2025-04-04
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-35922
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fbmon: prevent division by zero in fb_videomode_from_videomode() The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode(). Found by Linux Verification Center (linuxtesting.org) with Svace.

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35924
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Limit read size on v1.2 Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35925
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: block: prevent division by zero in blk_rq_stat_sum() The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero. Found by Linux Verification Center (linuxtesting.org) with Svace.

Published: 2024-05-19Modified: 2024-12-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35929
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: rcu/nocb: Fix WARN_ON_ONCE() in the rcu_nocb_bypass_lock() For the kernels built with CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y and CONFIG_RCU_LAZY=y, the following scenarios will trigger WARN_ON_ONCE() in the rcu_nocb_bypass_lock() and rcu_nocb_wait_contended() functions: CPU2 CPU11 kthread rcu_nocb_cb_kthread ksys_write rcu_do_batch vfs_write rcu_torture_timer_cb proc_sys_write __kmem_cache_free proc_sys_call_handler kmemleak_free drop_caches_sysctl_handler delete_object_full drop_slab __delete_object shrink_slab put_object lazy_rcu_shrink_scan call_rcu rcu_nocb_flush_bypass __call_rcu_commn rcu_nocb_bypass_lock raw_spin_trylock(&rdp->nocb_bypass_lock) fail atomic_inc(&rdp->nocb_lock_contended); rcu_nocb_wait_contended WARN_ON_ONCE(smp_processor_id() != rdp->cpu); WARN_ON_ONCE(atomic_read(&rdp->nocb_lock_contended)) | |_ _ _ _ _ _ _ _ _ _same rdp and rdp->cpu != 11_ _ _ _ _ _ _ _ _ __| Reproduce this bug with "echo 3 > /proc/sys/vm/drop_caches". This commit therefore uses rcu_nocb_try_flush_bypass() instead of rcu_nocb_flush_bypass() in lazy_rcu_shrink_scan(). If the nocb_bypass queue is being flushed, then rcu_nocb_try_flush_bypass will return directly.

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35930
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc() The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked. Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource.

Published: 2024-05-19Modified: 2024-12-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35932
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: don't check if plane->state->fb == state->fb Currently, when using non-blocking commits, we can see the following kernel warning: [ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- This happens because, although `prepare_fb` and `cleanup_fb` are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The opposite can also be true. In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the `drm_atomic_get_new_plane_state()` helper function should be used. So, we could stick to this check, but using `drm_atomic_get_new_plane_state()`. But actually, this check is not re ---truncated---

Published: 2024-05-19Modified: 2025-09-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35933
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Fix null ptr deref in btintel_read_version If hci_cmd_sync_complete() is triggered and skb is NULL, then hdev->req_skb is NULL, which will cause this issue.

Published: 2024-05-19Modified: 2026-01-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35934
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list() Many syzbot reports show extreme rtnl pressure, and many of them hint that smc acquires rtnl in netns creation for no good reason [1] This patch returns early from smc_pnet_net_init() if there is no netdevice yet. I am not even sure why smc_pnet_create_pnetids_list() even exists, because smc_pnet_netdev_event() is also calling smc_pnet_add_base_pnetid() when handling NETDEV_UP event. [1] extract of typical syzbot reports 2 locks held by syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878

Published: 2024-05-19Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35935
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: btrfs: send: handle path ref underflow in header iterate_inode_ref() Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.

Published: 2024-05-19Modified: 2025-12-23
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
References
CVE-2024-35936
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions: - at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1 - after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints

Published: 2024-05-19Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35937
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: check A-MSDU format more carefully If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.

Published: 2024-05-19Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35938
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: decrease MHI channel buffer length to 8KB Currently buf_len field of ath11k_mhi_config_qca6390 is assigned with 0, making MHI use a default size, 64KB, to allocate channel buffers. This is likely to fail in some scenarios where system memory is highly fragmented and memory compaction or reclaim is not allowed. There is a fail report which is caused by it: kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb Workqueue: events_unbound async_run_entry_fn Call Trace: dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/0x1b0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0 __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] device_for_each_child+0x5c/0xa0 ? __pfx_pci_pm_resume+0x10/0x10 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e] ? srso_alias_return_thunk+0x5/0xfbef5 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec] ? srso_alias_return_thunk+0x5/0xfbef5 dpm_run_callback+0x8c/0x1e0 device_resume+0x104/0x340 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x32/0x120 process_one_work+0x168/0x330 worker_thread+0x2f5/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe8/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Actually those buffers are used only by QMI target -> host communication. And for WCN6855 and QCA6390, the largest packet size for that is less than 6KB. So change buf_len field to 8KB, which results in order 1 allocation if page size is 4KB. In this way, we can at least save some memory, and as well as decrease the possibility of allocation failure in those scenarios. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35939
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: dma-direct: Leak pages on dma_set_decrypted() failure On TDX it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. DMA could free decrypted/shared pages if dma_set_decrypted() fails. This should be a rare case. Just leak the pages in this case instead of freeing them.

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35940
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pstore/zone: Add a null pointer check to the psz_kmsg_read kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.

Published: 2024-05-19Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35942
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of hdmi rx verification IP that should not enable for HDMI TX. But actually if the clock is disabled before HDMI/LCDIF probe, LCDIF will not get pixel clock from HDMI PHY and print the error logs: [CRTC:39:crtc-2] vblank wait timed out WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue.

Published: 2024-05-19Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35943
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pmdomain: ti: Add a null pointer check to the omap_prm_domain_init devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.

Published: 2024-05-19Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35944
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host() Syzkaller hit 'WARNING in dg_dispatch_as_host' bug. memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg" at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24) WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237 Some code commentry, based on my understanding: 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size) /// This is 24 + payload_size memcpy(&dg_info->msg, dg, dg_size); Destination = dg_info->msg ---> this is a 24 byte structure(struct vmci_datagram) Source = dg --> this is a 24 byte structure (struct vmci_datagram) Size = dg_size = 24 + payload_size {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32. 35 struct delayed_datagram_info { 36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg and msg_payload must be together. */ 40 struct vmci_datagram msg; 41 u8 msg_payload[]; 42 }; So those extra bytes of payload are copied into msg_payload[], a run time warning is seen while fuzzing with Syzkaller. One possible way to fix the warning is to split the memcpy() into two parts -- one -- direct assignment of msg and second taking care of payload. Gustavo quoted: "Under FORTIFY_SOURCE we should not copy data across multiple members in a structure."

Published: 2024-05-19Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35945
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: phy: phy_device: Prevent nullptr exceptions on ISR If phydev->irq is set unconditionally, check for valid interrupt handler or fall back to polling mode to prevent nullptr exceptions in interrupt service routine.

Published: 2024-05-19Modified: 2025-01-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35946
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix null pointer access when abort scan During cancel scan we might use vif that weren't scanning. Fix this by using the actual scanning vif.

Published: 2024-05-19Modified: 2025-01-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35947
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dyndbg: fix old BUG_ON in >control parser Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead.

Published: 2024-05-19Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35950
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/client: Fully protect modes[] with dev->mode_config.mutex The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.

Published: 2024-05-20Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35951
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr() If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called.

Published: 2024-05-20Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35952
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/ast: Fix soft lockup There is a while-loop in ast_dp_set_on_off() that could lead to infinite-loop. This is because the register, VGACRI-Dx, checked in this API is a scratch register actually controlled by a MCU, named DPMCU, in BMC. These scratch registers are protected by scu-lock. If suc-lock is not off, DPMCU can not update these registers and then host will have soft lockup due to never updated status. DPMCU is used to control DP and relative registers to handshake with host's VGA driver. Even the most time-consuming task, DP's link training, is less than 100ms. 200ms should be enough.

Published: 2024-05-20Modified: 2025-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35955
HIGH8.8

In the Linux kernel, the following vulnerability has been resolved: kprobes: Fix possible use-after-free issue on kprobe registration When unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will take a time. `is_module_text_address()` and `__module_text_address()` works with MODULE_STATE_LIVE and MODULE_STATE_GOING. If we use `is_module_text_address()` and `__module_text_address()` separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULE_STATE_UNFORMED between those operations. In `check_kprobe_address_safe()`, if the second `__module_text_address()` is failed, that is ignored because it expected a kernel_text address. But it may have failed simply because module->state has been changed to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify non-exist module text address (use-after-free). To fix this problem, we should not use separated `is_module_text_address()` and `__module_text_address()`, but use only `__module_text_address()` once and do `try_module_get(module)` which is only available with MODULE_STATE_LIVE.

Published: 2024-05-20Modified: 2025-04-04
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-35956
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations Create subvolume, create snapshot and delete subvolume all use btrfs_subvolume_reserve_metadata() to reserve metadata for the changes done to the parent subvolume's fs tree, which cannot be mediated in the normal way via start_transaction. When quota groups (squota or qgroups) are enabled, this reserves qgroup metadata of type PREALLOC. Once the operation is associated to a transaction, we convert PREALLOC to PERTRANS, which gets cleared in bulk at the end of the transaction. However, the error paths of these three operations were not implementing this lifecycle correctly. They unconditionally converted the PREALLOC to PERTRANS in a generic cleanup step regardless of errors or whether the operation was fully associated to a transaction or not. This resulted in error paths occasionally converting this rsv to PERTRANS without calling record_root_in_trans successfully, which meant that unless that root got recorded in the transaction by some other thread, the end of the transaction would not free that root's PERTRANS, leaking it. Ultimately, this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount for the leaked reservation. The fix is to ensure that every qgroup PREALLOC reservation observes the following properties: 1. any failure before record_root_in_trans is called successfully results in freeing the PREALLOC reservation. 2. after record_root_in_trans, we convert to PERTRANS, and now the transaction owns freeing the reservation. This patch enforces those properties on the three operations. Without it, generic/269 with squotas enabled at mkfs time would fail in ~5-10 runs on my system. With this patch, it ran successfully 1000 times in a row.

Published: 2024-05-20Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35958
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: ena: Fix incorrect descriptor free behavior ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDP_REDIRECT or XDP_TX instructions The ena_free_tx_bufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napi_consume_skb() for descriptors belonging to an XDP specific queue. This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.

Published: 2024-05-20Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35959
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix mlx5e_priv_init() cleanup flow When mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which calls mlx5e_selq_apply() that assures that the `priv->state_lock` is held using lockdep_is_held(). Acquire the state_lock in mlx5e_selq_cleanup(). Kernel log: ============================= WARNING: suspicious RCU usage 6.8.0-rc3_net_next_841a9b5 #1 Not tainted ----------------------------- drivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by systemd-modules/293: #0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core] #1: ffff8881096c65c0 (&device->client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core] stack backtrace: CPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x8a/0xa0 lockdep_rcu_suspicious+0x154/0x1a0 mlx5e_selq_apply+0x94/0xa0 [mlx5_core] mlx5e_selq_cleanup+0x3a/0x60 [mlx5_core] mlx5e_priv_init+0x2be/0x2f0 [mlx5_core] mlx5_rdma_setup_rn+0x7c/0x1a0 [mlx5_core] rdma_init_netdev+0x4e/0x80 [ib_core] ? mlx5_rdma_netdev_free+0x70/0x70 [mlx5_core] ipoib_intf_init+0x64/0x550 [ib_ipoib] ipoib_intf_alloc+0x4e/0xc0 [ib_ipoib] ipoib_add_one+0xb0/0x360 [ib_ipoib] add_client_context+0x112/0x1c0 [ib_core] ib_register_client+0x166/0x1b0 [ib_core] ? 0xffffffffa0573000 ipoib_init_module+0xeb/0x1a0 [ib_ipoib] do_one_initcall+0x61/0x250 do_init_module+0x8a/0x270 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x17d/0x230 __x64_sys_finit_module+0x61/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x46/0x4e

Published: 2024-05-20Modified: 2025-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35960
CRITICAL9.1

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Properly link new fs rules into the tree Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones. These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle.

Published: 2024-05-20Modified: 2025-04-04
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-35961
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Register devlink first under devlink lock In case device is having a non fatal FW error during probe, the driver will report the error to user via devlink. This will trigger a WARN_ON, since mlx5 is calling devlink_register() last. In order to avoid the WARN_ON[1], change mlx5 to invoke devl_register() first under devlink lock. [1] WARNING: CPU: 5 PID: 227 at net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0 CPU: 5 PID: 227 Comm: kworker/u16:3 Not tainted 6.4.0-rc5_for_upstream_min_debug_2023_06_12_12_38 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_health0000:08:00.0 mlx5_fw_reporter_err_work [mlx5_core] RIP: 0010:devlink_recover_notify.constprop.0+0xb8/0xc0 Call Trace: ? __warn+0x79/0x120 ? devlink_recover_notify.constprop.0+0xb8/0xc0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? devlink_recover_notify.constprop.0+0xb8/0xc0 devlink_health_report+0x4a/0x1c0 mlx5_fw_reporter_err_work+0xa4/0xd0 [mlx5_core] process_one_work+0x1bb/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x4d/0x3c0 ? process_one_work+0x3c0/0x3c0 kthread+0xc6/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30

Published: 2024-05-20Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35963
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sock: Fix not validating setsockopt user input Check user input length before copying data.

Published: 2024-05-20Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35964
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix not validating setsockopt user input Check user input length before copying data.

Published: 2024-05-20Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35965
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix not validating setsockopt user input Check user input length before copying data.

Published: 2024-05-20Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35966
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix not validating setsockopt user input syzbot reported rfcomm_sock_setsockopt_old() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old net/bluetooth/rfcomm/sock.c:632 [inline] BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70 net/bluetooth/rfcomm/sock.c:673 Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064

Published: 2024-05-20Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35967
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix not validating setsockopt user input syzbot reported sco_sock_setsockopt() is copying data without checking user input length. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578

Published: 2024-05-20Modified: 2025-12-23
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-35969
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it still means hlist_for_each_entry_rcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane. In particular, the reference count can be zero. This can happen if ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough timing, this can happen: 1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry. 2. Then, the whole ipv6_del_addr is executed for the given entry. The reference count drops to zero and kfree_rcu is scheduled. 3. ipv6_get_ifaddr continues and tries to increments the reference count (in6_ifa_hold). 4. The rcu is unlocked and the entry is freed. 5. The freed entry is returned. Prevent increasing of the reference count in such case. The name in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe. [ 41.506330] refcount_t: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] [ 41.517249] ? __warn+0x7b/0x120 [ 41.517535] ? refcount_warn_saturate+0xa5/0x130 [ 41.517923] ? report_bug+0x164/0x190 [ 41.518240] ? handle_bug+0x3d/0x70 [ 41.518541] ? exc_invalid_op+0x17/0x70 [ 41.520972] ? asm_exc_invalid_op+0x1a/0x20 [ 41.521325] ? refcount_warn_saturate+0xa5/0x130 [ 41.521708] ipv6_get_ifaddr+0xda/0xe0 [ 41.522035] inet6_rtm_getaddr+0x342/0x3f0 [ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10 [ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0 [ 41.523102] ? netlink_unicast+0x30f/0x390 [ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 41.523832] netlink_rcv_skb+0x53/0x100 [ 41.524157] netlink_unicast+0x23b/0x390 [ 41.524484] netlink_sendmsg+0x1f2/0x440 [ 41.524826] __sys_sendto+0x1d8/0x1f0 [ 41.525145] __x64_sys_sendto+0x1f/0x30 [ 41.525467] do_syscall_64+0xa5/0x1b0 [ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated---

Published: 2024-05-20Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35970
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket. With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue.

Published: 2024-05-20Modified: 2025-04-04
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
References
CVE-2024-35971
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Handle softirqs at the end of IRQ thread to fix hang The ks8851_irq() thread may call ks8851_rx_pkts() in case there are any packets in the MAC FIFO, which calls netif_rx(). This netif_rx() implementation is guarded by local_bh_disable() and local_bh_enable(). The local_bh_enable() may call do_softirq() to run softirqs in case any are pending. One of the softirqs is net_rx_action, which ultimately reaches the driver .start_xmit callback. If that happens, the system hangs. The entire call chain is below: ks8851_start_xmit_par from netdev_start_xmit netdev_start_xmit from dev_hard_start_xmit dev_hard_start_xmit from sch_direct_xmit sch_direct_xmit from __dev_queue_xmit __dev_queue_xmit from __neigh_update __neigh_update from neigh_update neigh_update from arp_process.constprop.0 arp_process.constprop.0 from __netif_receive_skb_one_core __netif_receive_skb_one_core from process_backlog process_backlog from __napi_poll.constprop.0 __napi_poll.constprop.0 from net_rx_action net_rx_action from __do_softirq __do_softirq from call_with_stack call_with_stack from do_softirq do_softirq from __local_bh_enable_ip __local_bh_enable_ip from netif_rx netif_rx from ks8851_irq ks8851_irq from irq_thread_fn irq_thread_fn from irq_thread irq_thread from kthread kthread from ret_from_fork The hang happens because ks8851_irq() first locks a spinlock in ks8851_par.c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) and with that spinlock locked, calls netif_rx(). Once the execution reaches ks8851_start_xmit_par(), it calls ks8851_lock_par() again which attempts to claim the already locked spinlock again, and the hang happens. Move the do_softirq() call outside of the spinlock protected section of ks8851_irq() by disabling BHs around the entire spinlock protected section of ks8851_irq() handler. Place local_bh_enable() outside of the spinlock protected section, so that it can trigger do_softirq() without the ks8851_par.c ks8851_lock_par() spinlock being held, and safely call ks8851_start_xmit_par() without attempting to lock the already locked spinlock. Since ks8851_irq() is protected by local_bh_disable()/local_bh_enable() now, replace netif_rx() with __netif_rx() which is not duplicating the local_bh_disable()/local_bh_enable() calls.

Published: 2024-05-20Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35972
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init() If ulp = kzalloc() fails, the allocated edev will leak because it is not properly assigned and the cleanup path will not be able to free it. Fix it by assigning it properly immediately after allocation.

Published: 2024-05-20Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35973
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: geneve: fix header validation in geneve[6]_xmit_skb syzbot is able to trigger an uninit-value in geneve_xmit() [1] Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb->protocol. If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol, pskb_inet_may_pull() does nothing at all. If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected. Add skb_vlan_inet_prepare() to perform a complete mac validation. Use this in geneve for the moment, I suspect we need to adopt this more broadly. v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types. v2,v3 - Addressed Sabrina comments on v1 and v2 [1] BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024

Published: 2024-05-20Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35974
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: block: fix q->blkg_list corruption during disk rebind Multiple gendisk instances can allocated/added for single request queue in case of disk rebind. blkg may still stay in q->blkg_list when calling blkcg_init_disk() for rebind, then q->blkg_list becomes corrupted. Fix the list corruption issue by: - add blkg_init_queue() to initialize q->blkg_list & q->blkcg_mutex only - move calling blkg_init_queue() into blk_alloc_queue() The list corruption should be started since commit f1c006f1c685 ("blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()") which delays removing blkg from q->blkg_list into blkg_free_workfn().

Published: 2024-05-20Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35976
MEDIUM6.7

In the Linux kernel, the following vulnerability has been resolved: xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING syzbot reported an illegal copy in xsk_setsockopt() [1] Make sure to validate setsockopt() @optlen parameter. [1] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549 CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2) The buggy address belongs to the physical page: page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncated---

Published: 2024-05-20Modified: 2025-11-04
CVSS 3.xMEDIUM 6.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
References
CVE-2024-35978
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix memory leak in hci_req_sync_complete() In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one.

Published: 2024-05-20Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35981
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: virtio_net: Do not send RSS key if it is not supported There is a bug when setting the RSS options in virtio_net that can break the whole machine, getting the kernel into an infinite loop. Running the following command in any QEMU virtual machine with virtionet will reproduce this problem: # ethtool -X eth0 hfunc toeplitz This is how the problem happens: 1) ethtool_set_rxfh() calls virtnet_set_rxfh() 2) virtnet_set_rxfh() calls virtnet_commit_rss_command() 3) virtnet_commit_rss_command() populates 4 entries for the rss scatter-gather 4) Since the command above does not have a key, then the last scatter-gatter entry will be zeroed, since rss_key_size == 0. sg_buf_size = vi->rss_key_size; 5) This buffer is passed to qemu, but qemu is not happy with a buffer with zero length, and do the following in virtqueue_map_desc() (QEMU function): if (!sz) { virtio_error(vdev, "virtio: zero sized buffers are not allowed"); 6) virtio_error() (also QEMU function) set the device as broken vdev->broken = true; 7) Qemu bails out, and do not repond this crazy kernel. 8) The kernel is waiting for the response to come back (function virtnet_send_command()) 9) The kernel is waiting doing the following : while (!virtqueue_get_buf(vi->cvq, &tmp) && !virtqueue_is_broken(vi->cvq)) cpu_relax(); 10) None of the following functions above is true, thus, the kernel loops here forever. Keeping in mind that virtqueue_is_broken() does not look at the qemu `vdev->broken`, so, it never realizes that the vitio is broken at QEMU side. Fix it by not sending RSS commands if the feature is not available in the device.

Published: 2024-05-20Modified: 2025-01-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35982
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes. While this should be handled proactively when: * interface with too low MTU is added * VLAN is added * non-purgeable local mac is added * MTU of an attached interface is reduced * fragmentation setting gets disabled (which most likely requires dropping attached interfaces) not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present.

Published: 2024-05-20Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35984
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions]

Published: 2024-05-20Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35986
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: phy: ti: tusb1210: Resolve charger-det crash if charger psy is unregistered The power_supply frame-work is not really designed for there to be long living in kernel references to power_supply devices. Specifically unregistering a power_supply while some other code has a reference to it triggers a WARN in power_supply_unregister(): WARN_ON(atomic_dec_return(&psy->use_cnt)); Folllowed by the power_supply still getting removed and the backing data freed anyway, leaving the tusb1210 charger-detect code with a dangling reference, resulting in a crash the next time tusb1210_get_online() is called. Fix this by only holding the reference in tusb1210_get_online() freeing it at the end of the function. Note this still leaves a theoretical race window, but it avoids the issue when manually rmmod-ing the charger chip driver during development.

Published: 2024-05-20Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35988
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: riscv: Fix TASK_SIZE on 64-bit NOMMU On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASK_SIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines.

Published: 2024-05-20Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35989
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix oops during rmmod on single-CPU platforms During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Fix the issue by preventing the migration of the perf context to an invalid target.

Published: 2024-05-20Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35990
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dma: xilinx_dpdma: Fix locking There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like [ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated---

Published: 2024-05-20Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35992
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: phy: marvell: a3700-comphy: Fix out of bounds read There is an out of bounds read access of 'gbe_phy_init_fix[fix_idx].addr' every iteration after 'fix_idx' reaches 'ARRAY_SIZE(gbe_phy_init_fix)'. Make sure 'gbe_phy_init[addr]' is used when all elements of 'gbe_phy_init_fix' array are handled. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-05-20Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35995
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Use access_width over bit_width for system memory accesses To align with ACPI 6.3+, since bit_width can be any 8-bit value, it cannot be depended on to be always on a clean 8b boundary. This was uncovered on the Cobalt 100 platform. SError Interrupt on CPU26, code 0xbe000011 -- SError CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--) pc : cppc_get_perf_caps+0xec/0x410 lr : cppc_get_perf_caps+0xe8/0x410 sp : ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Call trace: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x90 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_online+0x2dc/0xa30 cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Instead, use access_width to determine the size and use the offset and width to shift and mask the bits to read/write out. Make sure to add a check for system memory since pcc redefines the access_width to subspace id. If access_width is not set, then fall back to using bit_width. [ rjw: Subject and changelog edits, comment adjustments ]

Published: 2024-05-20Modified: 2025-09-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35997
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that. More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop. Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up. Delete this unnecessary flag.

Published: 2024-05-20Modified: 2025-01-16
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35998
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: smb3: fix lock ordering potential deadlock in cifs_sync_mid_result Coverity spotted that the cifs_sync_mid_result function could deadlock "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock" Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)")

Published: 2024-05-20Modified: 2025-01-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-35999
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: smb3: missing lock when picking channel Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index. Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")

Published: 2024-05-20Modified: 2025-04-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36000
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix missing hugetlb_lock for resv uncharge There is a recent report on UFFDIO_COPY over hugetlb: https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/ 350: lockdep_assert_held(&hugetlb_lock); Should be an issue in hugetlb but triggered in an userfault context, where it goes into the unlikely path where two threads modifying the resv map together. Mike has a fix in that path for resv uncharge but it looks like the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd() will update the cgroup pointer, so it requires to be called with the lock held.

Published: 2024-05-20Modified: 2025-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36004
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i40e: Do not use WQ_MEM_RECLAIM flag for workqueue Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in check_flush_dependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQ_MEM_RECLAIM flag, and the i40iw one is not. Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too. [Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is flushing !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40e_service_task [i40e] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] [ +0.000002] ? __warn+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? report_bug+0x195/0x1a0 [ +0.000005] ? handle_bug+0x3c/0x70 [ +0.000003] ? exc_invalid_op+0x14/0x70 [ +0.000002] ? asm_exc_invalid_op+0x16/0x20 [ +0.000006] ? check_flush_dependency+0x10b/0x120 [ +0.000002] ? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000024] process_one_work+0x174/0x340 [ +0.000003] worker_th ---truncated---

Published: 2024-05-20Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36005
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: honor table dormant flag from netdev release event path Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook. [524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanup_net [524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] [524854.859013] ? __warn+0x9f/0x1a0 [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859044] ? report_bug+0x1b1/0x1e0 [524854.859060] ? handle_bug+0x3c/0x70 [524854.859071] ? exc_invalid_op+0x17/0x40 [524854.859083] ? asm_exc_invalid_op+0x1a/0x20 [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260 [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables] [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859461] ? packet_notifier+0xb3/0x360 [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40 [524854.859489] ? dcbnl_netdevice_event+0x35/0x140 [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859661] notifier_call_chain+0x7d/0x140 [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

Published: 2024-05-20Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36006
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix incorrect list API usage Both the function that migrates all the chunks within a region and the function that migrates all the entries within a chunk call list_first_entry() on the respective lists without checking that the lists are not empty. This is incorrect usage of the API, which leads to the following warning [1]. Fix by returning if the lists are empty as there is nothing to migrate in this case. [1] WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0> Modules linked in: CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0 [...] Call Trace: mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30

Published: 2024-05-20Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36007
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix warning during rehash As previously explained, the rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters. When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled. Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1]. Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases. [1] WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_afk_encode+0x242/0x2f0 [...] Call Trace: mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50

Published: 2024-05-20Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36008
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv4: check for NULL idev in ip_route_use_hint() syzbot was able to trigger a NULL deref in fib_validate_source() in an old tree [1]. It appears the bug exists in latest trees. All calls to __in_dev_get_rcu() must be checked for a NULL result. [1] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231 ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline] ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673 __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline] __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 __netif_receive_skb_list net/core/dev.c:5672 [inline] netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764 netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 xdp_recv_frames net/bpf/test_run.c:257 [inline] xdp_test_run_batch net/bpf/test_run.c:335 [inline] bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736 __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115 __do_sys_bpf kernel/bpf/syscall.c:5201 [inline] __se_sys_bpf kernel/bpf/syscall.c:5199 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199

Published: 2024-05-20Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36009
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ax25: Fix netdev refcount issue The dev_tracker is added to ax25_cb in ax25_bind(). When the ax25 device is detaching, the dev_tracker of ax25_cb should be deallocated in ax25_kill_by_device() instead of the dev_tracker of ax25_dev. The log reported by ref_tracker is shown below: [ 80.884935] ref_tracker: reference already released. [ 80.885150] ref_tracker: allocated in: [ 80.885349] ax25_dev_device_up+0x105/0x540 [ 80.885730] ax25_device_event+0xa4/0x420 [ 80.885730] notifier_call_chain+0xc9/0x1e0 [ 80.885730] __dev_notify_flags+0x138/0x280 [ 80.885730] dev_change_flags+0xd7/0x180 [ 80.885730] dev_ifsioc+0x6a9/0xa30 [ 80.885730] dev_ioctl+0x4d8/0xd90 [ 80.885730] sock_do_ioctl+0x1c2/0x2d0 [ 80.885730] sock_ioctl+0x38b/0x4f0 [ 80.885730] __se_sys_ioctl+0xad/0xf0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 80.885730] ref_tracker: freed in: [ 80.885730] ax25_device_event+0x272/0x420 [ 80.885730] notifier_call_chain+0xc9/0x1e0 [ 80.885730] dev_close_many+0x272/0x370 [ 80.885730] unregister_netdevice_many_notify+0x3b5/0x1180 [ 80.885730] unregister_netdev+0xcf/0x120 [ 80.885730] sixpack_close+0x11f/0x1b0 [ 80.885730] tty_ldisc_kill+0xcb/0x190 [ 80.885730] tty_ldisc_hangup+0x338/0x3d0 [ 80.885730] __tty_hangup+0x504/0x740 [ 80.885730] tty_release+0x46e/0xd80 [ 80.885730] __fput+0x37f/0x770 [ 80.885730] __x64_sys_close+0x7b/0xb0 [ 80.885730] do_syscall_64+0xc4/0x1b0 [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f [ 80.893739] ------------[ cut here ]------------ [ 80.894030] WARNING: CPU: 2 PID: 140 at lib/ref_tracker.c:255 ref_tracker_free+0x47b/0x6b0 [ 80.894297] Modules linked in: [ 80.894929] CPU: 2 PID: 140 Comm: ax25_conn_rel_6 Not tainted 6.9.0-rc4-g8cd26fd90c1a #11 [ 80.895190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4 [ 80.895514] RIP: 0010:ref_tracker_free+0x47b/0x6b0 [ 80.895808] Code: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9 [ 80.896171] RSP: 0018:ffff888009edf8c0 EFLAGS: 00000286 [ 80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000 [ 80.896502] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff88800a0d6518 [ 80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a [ 80.897212] R10: dffffc0000000000 R11: ffffed100da6511b R12: ffff88800a4a31d4 [ 80.897859] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518 [ 80.898279] FS: 00007fd88b7fe700(0000) GS:ffff88806d300000(0000) knlGS:0000000000000000 [ 80.899436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 80.900181] CR2: 00007fd88c001d48 CR3: 000000000993e000 CR4: 00000000000006f0 ... [ 80.935774] ref_tracker: sp%d@000000000bb9df3d has 1/1 users at [ 80.935774] ax25_bind+0x424/0x4e0 [ 80.935774] __sys_bind+0x1d9/0x270 [ 80.935774] __x64_sys_bind+0x75/0x80 [ 80.935774] do_syscall_64+0xc4/0x1b0 [ 80.935774] entry_SYSCALL_64_after_hwframe+0x67/0x6f Change ax25_dev->dev_tracker to the dev_tracker of ax25_cb in order to mitigate the bug.

Published: 2024-05-20Modified: 2025-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36012
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: msft: fix slab-use-after-free in msft_do_close() Tying the msft->data lifetime to hdev by freeing it in hci_release_dev() to fix the following case: [use] msft_do_close() msft = hdev->msft_data; if (!msft) ...(1) <- passed. return; mutex_lock(&msft->filter_lock); ...(4) <- used after freed. [free] msft_unregister() msft = hdev->msft_data; hdev->msft_data = NULL; ...(2) kfree(msft); ...(3) <- msft is freed. ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30 kernel/locking/mutex.c:752 Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309

Published: 2024-05-23Modified: 2025-01-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36013
MEDIUM6.8

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect() Extend a critical section to prevent chan from early freeing. Also make the l2cap_connect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix. Call stack summary: [use] l2cap_bredr_sig_cmd l2cap_connect ┌ mutex_lock(&conn->chan_lock); │ chan = pchan->ops->new_connection(pchan); <- alloc chan │ __l2cap_chan_add(conn, chan); │ l2cap_chan_hold(chan); │ list_add(&chan->list, &conn->chan_l); ... (1) └ mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free [free] l2cap_conn_del ┌ mutex_lock(&conn->chan_lock); │ foreach chan in conn->chan_l: ... (2) │ l2cap_chan_put(chan); │ l2cap_chan_destroy │ kfree(chan) ... (3) <- chan freed └ mutex_unlock(&conn->chan_lock); ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0 net/bluetooth/l2cap_core.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311

Published: 2024-05-23Modified: 2025-04-01
CVSS 3.xMEDIUM 6.8
CVSS:3.x/CVSS:3.1/AV:A/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
References
CVE-2024-36014
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/arm/malidp: fix a possible null pointer dereference In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset.

Published: 2024-05-29Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36015
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ppdev: Add an error check in register_device In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value. To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded.

Published: 2024-05-29Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36016
HIGH7.7

In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size.

Published: 2024-05-29Modified: 2025-11-04
CVSS 3.xHIGH 7.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36017
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.

Published: 2024-05-30Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36020
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i40e: fix vf may be used uninitialized in this function warning To fix the regression introduced by commit 52424f974bc5, which causes servers hang in very hard to reproduce conditions with resets races. Using two sources for the information is the root cause. In this function before the fix bumping v didn't mean bumping vf pointer. But the code used this variables interchangeably, so stale vf could point to different/not intended vf. Remove redundant "v" variable and iterate via single VF pointer across whole function instead to guarantee VF pointer validity.

Published: 2024-05-30Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36021
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when devlink reload during pf initialization The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devl_lock during initialization.

Published: 2024-05-30Modified: 2025-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36023
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Julia Lawall reported this null pointer dereference, this should fix it.

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36025
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix off by one in qla_edif_app_getstats() The app_reply->elem[] array is allocated earlier in this function and it has app_req.num_ports elements. Thus this > comparison needs to be >= to prevent memory corruption.

Published: 2024-05-30Modified: 2025-09-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36026
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11 While doing multiple S4 stress tests, GC/RLC/PMFW get into an invalid state resulting into hard hangs. Adding a GFX reset as workaround just before sending the MP1_UNLOAD message avoids this failure.

Published: 2024-05-30Modified: 2025-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36028
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio() When I did memory failure tests recently, below warning occurs: DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0 Modules linked in: mce_inject hwpoison_inject CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 FS: 00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0 Call Trace: lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 Kernel panic - not syncing: kernel: panic_on_warn set ... CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: panic+0x326/0x350 check_panic_on_warn+0x4f/0x50 __warn+0x98/0x190 report_bug+0x18e/0x1a0 handle_bug+0x3d/0x70 exc_invalid_op+0x18/0x70 asm_exc_invalid_op+0x1a/0x20 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004 lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 After git bisecting and digging into the code, I believe the root cause is that _deferred_list field of folio is unioned with _hugetlb_subpool field. In __update_and_free_hugetlb_folio(), folio->_deferred_ ---truncated---

Published: 2024-05-30Modified: 2025-09-18
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36029
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mmc: sdhci-msm: pervent access to suspended controller Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.

Published: 2024-05-30Modified: 2025-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36031
CRITICAL9.8

In the Linux kernel, the following vulnerability has been resolved: keys: Fix overwrite of key expiration on instantiation The expiry time of a key is unconditionally overwritten during instantiation, defaulting to turn it permanent. This causes a problem for DNS resolution as the expiration set by user-space is overwritten to TIME64_MAX, disabling further DNS updates. Fix this by restoring the condition that key_set_expiry is only called when the pre-parser sets a specific expiry.

Published: 2024-05-30Modified: 2025-11-04
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36032
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix info leak when fetching fw build id Add the missing sanity checks and move the 255-byte build-id buffer off the stack to avoid leaking stack data through debugfs in case the build-info reply is malformed.

Published: 2024-05-30Modified: 2025-09-18
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36244
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: extend minimum interval restriction to entire cycle too It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals. We need one more restriction, which is that the cycle time itself must be larger than N * ETH_ZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycle_time)" branch. This way covers both conditions and scenarios. Add a selftest which illustrates the issue triggered by syzbot.

Published: 2024-06-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36270
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: tproxy: bail out if IP has been disabled on the device syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() can return NULL, so check for this.

Published: 2024-06-21Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36286
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() syzbot reported that nf_reinject() could be called without rcu_read_lock() : WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36479
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fpga: bridge: add owner module and take its refcount The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge. Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions.

Published: 2024-06-24Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36481
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tracing/probes: fix error check in parse_btf_field() btf_find_struct_member() might return NULL or an error via the ERR_PTR() macro. However, its caller in parse_btf_field() only checks for the NULL condition. Fix this by using IS_ERR() and returning the error up the stack.

Published: 2024-06-21Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36489
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tls: fix missing memory barrier in tls_init In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot.

Published: 2024-06-21Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36880
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: add missing firmware sanity checks Add the missing sanity checks when parsing the firmware files before downloading them to avoid accessing and corrupting memory beyond the vmalloced buffer.

Published: 2024-05-30Modified: 2025-09-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36881
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: reset ptes when close() for wr-protected ones Userfaultfd unregister includes a step to remove wr-protect bits from all the relevant pgtable entries, but that only covered an explicit UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover that too. This fixes a WARN trace. The only user visible side effect is the user can observe leftover wr-protect bits even if the user close()ed on an userfaultfd when releasing the last reference of it. However hopefully that should be harmless, and nothing bad should happen even if so. This change is now more important after the recent page-table-check patch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check: support userfault wr-protect entries")), as we'll do sanity check on uffd-wp bits without vma context. So it's better if we can 100% guarantee no uffd-wp bit leftovers, to make sure each report will be valid.

Published: 2024-05-30Modified: 2025-04-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36882
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm: use memalloc_nofs_save() in page_cache_ra_order() See commit f2c817bed58d ("mm: use memalloc_nofs_save in readahead path"), ensure that page_cache_ra_order() do not attempt to reclaim file-backed pages too, or it leads to a deadlock, found issue when test ext4 large folio. INFO: task DataXceiver for:7494 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200 Call trace: __switch_to+0x14c/0x240 __schedule+0x82c/0xdd0 schedule+0x58/0xf0 io_schedule+0x24/0xa0 __folio_lock+0x130/0x300 migrate_pages_batch+0x378/0x918 migrate_pages+0x350/0x700 compact_zone+0x63c/0xb38 compact_zone_order+0xc0/0x118 try_to_compact_pages+0xb0/0x280 __alloc_pages_direct_compact+0x98/0x248 __alloc_pages+0x510/0x1110 alloc_pages+0x9c/0x130 folio_alloc+0x20/0x78 filemap_alloc_folio+0x8c/0x1b0 page_cache_ra_order+0x174/0x308 ondemand_readahead+0x1c8/0x2b8 page_cache_async_ra+0x68/0xb8 filemap_readahead.isra.0+0x64/0xa8 filemap_get_pages+0x3fc/0x5b0 filemap_splice_read+0xf4/0x280 ext4_file_splice_read+0x2c/0x48 [ext4] vfs_splice_read.part.0+0xa8/0x118 splice_direct_to_actor+0xbc/0x288 do_splice_direct+0x9c/0x108 do_sendfile+0x328/0x468 __arm64_sys_sendfile64+0x8c/0x148 invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x4c/0x1f8 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190

Published: 2024-05-30Modified: 2025-01-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36883
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: net: fix out-of-bounds access in ops_init net_alloc_generic is called by net_alloc, which is called without any locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access. It is possible that the array is allocated and another thread is registering a new pernet ops, increments max_gen_ptrs, which is then used to set s.len with a larger than allocated length for the variable array. Fix it by reading max_gen_ptrs only once in net_alloc_generic. If max_gen_ptrs is later incremented, it will be caught in net_assign_generic.

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36886
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in error path Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path: BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034 CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576 napi_poll linux/net/core/dev.c:6645 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553 do_softirq linux/kernel/softirq.c:454 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441 __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381 local_bh_enable linux/./include/linux/bottom_half.h:33 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378 dev_queue_xmit linux/./include/linux/netdevice.h:3169 neigh_hh_output linux/./include/net/neighbour.h:526 neigh_output linux/./include/net/neighbour.h:540 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235 __ip_finish_output linux/net/ipv4/ip_output.c:313 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323 NF_HOOK_COND linux/./include/linux/netfilter.h:303 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433 dst_output linux/./include/net/dst.h:451 ip_local_out linux/net/ipv4/ip_output.c:129 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850 sock_sendmsg_nosec linux/net/socket.c:730 __sock_sendmsg linux/net/socket.c:745 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191 __do_sys_sendto linux/net/socket.c:2203 __se_sys_sendto linux/net/socket.c:2199 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199 do_syscall_x64 linux/arch/x86/entry/common.c:52 do_syscall_ ---truncated---

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36889
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure snd_nxt is properly initialized on connect Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time.

Published: 2024-05-30Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36891
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix mas_empty_area_rev() null pointer dereference Currently the code calls mas_start() followed by mas_data_end() if the maple state is MA_START, but mas_start() may return with the maple state node == NULL. This will lead to a null pointer dereference when checking information in the NULL node, which is done in mas_data_end(). Avoid setting the offset if there is no node by waiting until after the maple state is checked for an empty or single entry state. A user could trigger the events to cause a kernel oops by unmapping all vmas to produce an empty maple tree, then mapping a vma that would cause the scenario described above.

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36893
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Check for port partner validity before consuming it typec_register_partner() does not guarantee partner registration to always succeed. In the event of failure, port->partner is set to the error value or NULL. Given that port->partner validity is not checked, this results in the following crash: Unable to handle kernel NULL pointer dereference at virtual address xx pc : run_state_machine+0x1bc8/0x1c08 lr : run_state_machine+0x1b90/0x1c08 .. Call trace: run_state_machine+0x1bc8/0x1c08 tcpm_state_machine_work+0x94/0xe4 kthread_worker_fn+0x118/0x328 kthread+0x1d0/0x23c ret_from_fork+0x10/0x20 To prevent the crash, check for port->partner validity before derefencing it in all the call sites.

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36894
MEDIUM5.6

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following: DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock. Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it. This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")

Published: 2024-05-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.6
CVSS:3.x/CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36896
CRITICAL9.1

In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix access violation during port device removal Testing with KASAN and syzkaller revealed a bug in port.c:disable_store(): usb_hub_to_struct_hub() can return NULL if the hub that the port belongs to is concurrently removed, but the function does not check for this possibility before dereferencing the returned value. It turns out that the first dereference is unnecessary, since hub->intfdev is the parent of the port device, so it can be changed easily. Adding a check for hub == NULL prevents further problems. The same bug exists in the disable_show() routine, and it can be fixed the same way.

Published: 2024-05-30Modified: 2025-04-01
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-36897
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Atom Integrated System Info v2_2 for DCN35 New request from KMD/VBIOS in order to support new UMA carveout model. This fixes a null dereference from accessing Ctx->dc_bios->integrated_info while it was NULL. DAL parses through the BIOS and extracts the necessary integrated_info but was missing a case for the new BIOS version 2.3.

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36898
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active.

Published: 2024-05-30Modified: 2026-04-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36899
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Fix use after free in lineinfo_changed_notify The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain.

Published: 2024-05-30Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36900
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when devlink reload during initialization The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by registering the devlink after hardware initialization.

Published: 2024-05-30Modified: 2025-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36901
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36902
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action() syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36903
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix potential uninit-value access in __ip6_make_skb() As it was done in commit fc1092f51567 ("ipv4: Fix uninit-value access in __ip_make_skb()") for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6->flowi6_flags instead of testing HDRINCL on the socket to avoid a race condition which causes uninit-value access.

Published: 2024-05-30Modified: 2026-01-19
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36904
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: tcp: Use refcount_inc_not_zero() in tcp_twsk_unique(). Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique() with nice analysis. Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inet_twsk_hashdance() sets TIME-WAIT socket's sk_refcnt after putting it into ehash and releasing the bucket lock. Thus, there is a small race window where other threads could try to reuse the port during connect() and call sock_hold() in tcp_twsk_unique() for the TIME-WAIT socket with zero refcnt. If that happens, the refcnt taken by tcp_twsk_unique() is overwritten and sock_put() will cause underflow, triggering a real use-after-free somewhere else. To avoid the use-after-free, we need to use refcount_inc_not_zero() in tcp_twsk_unique() and give up on reusing the port if it returns false. [0]: refcount_t: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcount_warn_saturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: ? refcount_warn_saturate+0xe5/0x110 ? __warn+0x81/0x130 ? refcount_warn_saturate+0xe5/0x110 ? report_bug+0x171/0x1a0 ? refcount_warn_saturate+0xe5/0x110 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? refcount_warn_saturate+0xe5/0x110 tcp_twsk_unique+0x186/0x190 __inet_check_established+0x176/0x2d0 __inet_hash_connect+0x74/0x7d0 ? __pfx___inet_check_established+0x10/0x10 tcp_v4_connect+0x278/0x530 __inet_stream_connect+0x10f/0x3d0 inet_stream_connect+0x3a/0x60 __sys_connect+0xa8/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0x83/0x170 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36905
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers. In the following crash [1], syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust() A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called. TCP_CLOSE connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1 To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway. When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state. This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations. [1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36906
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ARM: 9381/1: kasan: clear stale stack poison We found below OOB crash: [ 33.452494] ================================================================== [ 33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0 [ 33.455515] [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.1.25-mainline #1 [ 33.456880] Hardware name: Generic DT based system [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4 [ 33.459863] print_report from kasan_report+0x9c/0x148 [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0 [ 33.461424] kasan_check_range from memset+0x20/0x3c [ 33.462157] memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec [ 33.463064] refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354 [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24 [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4 [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18 [ 33.467397] [ 33.467644] The buggy address belongs to stack of task swapper/0/0 [ 33.468493] and is located at offset 112 in frame: [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec [ 33.469917] [ 33.470165] This frame has 2 objects: [ 33.470696] [32, 76) 'global_zone_diff' [ 33.470729] [112, 276) 'global_node_diff' [ 33.471294] [ 33.472095] The buggy address belongs to the physical page: [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03 [ 33.473944] flags: 0x1000(reserved|zone=0) [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001 [ 33.475656] raw: 00000000 [ 33.476050] page dumped because: kasan: bad access detected [ 33.476816] [ 33.477061] Memory state around the buggy address: [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1 [ 33.480415] ^ [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3 [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 [ 33.482978] ================================================================== We find the root cause of this OOB is that arm does not clear stale stack poison in the case of cpuidle. This patch refer to arch/arm64/kernel/sleep.S to resolve this issue. From cited commit [1] that explain the problem Functions which the compiler has instrumented for KASAN place poison on the stack shadow upon entry and remove this poison prior to returning. In the case of cpuidle, CPUs exit the kernel a number of levels deep in C code. Any instrumented functions on this critical path will leave portions of the stack shadow poisoned. If CPUs lose context and return to the kernel via a cold path, we restore a prior context saved in __cpu_suspend_enter are forgotten, and we never remove the poison they placed in the stack shadow area by functions calls between this and the actual exit of the kernel. Thus, (depending on stackframe layout) subsequent calls to instrumented functions may hit this stale poison, resulting in (spurious) KASAN splats to the console. To avoid this, clear any stale poison from the idle thread for a CPU prior to bringing a CPU online. From cited commit [2] Extend to check for CONFIG_KASAN_STACK [1] commit 0d97e6d8024c ("arm64: kasan: clear stale stack poison") [2] commit d56a9ef84bd0 ("kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK")

Published: 2024-05-30Modified: 2025-09-17
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36908
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk.

Published: 2024-05-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36909
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encrypted In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus ring buffer code could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the struct vmbus_gpadl for the ring buffers to decide whether to free the memory.

Published: 2024-05-30Modified: 2025-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36910
MEDIUM6.2

In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Don't free decrypted memory In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus device UIO driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.

Published: 2024-05-30Modified: 2025-04-01
CVSS 3.xMEDIUM 6.2
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36911
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Don't free decrypted memory In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The netvsc driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.

Published: 2024-05-30Modified: 2025-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36912
HIGH8.1

In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. In order to make sure callers of vmbus_establish_gpadl() and vmbus_teardown_gpadl() don't return decrypted/shared pages to allocators, add a field in struct vmbus_gpadl to keep track of the decryption status of the buffers. This will allow the callers to know if they should free or leak the pages.

Published: 2024-05-30Modified: 2025-11-18
CVSS 3.xHIGH 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36913
HIGH8.1

In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. VMBus code could free decrypted pages if set_memory_encrypted()/decrypted() fails. Leak the pages if this happens.

Published: 2024-05-30Modified: 2025-11-14
CVSS 3.xHIGH 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36914
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip on writeback when it's not applicable [WHY] dynamic memory safety error detector (KASAN) catches and generates error messages "BUG: KASAN: slab-out-of-bounds" as writeback connector does not support certain features which are not initialized. [HOW] Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.

Published: 2024-05-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36915
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies syzbot reported unsafe calls to copy_from_sockptr() [1] Use copy_safe_from_sockptr() instead. [1] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255 Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078 CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255 do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfd/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7f7fac07fd89 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89 RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

Published: 2024-05-30Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36916
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: blk-iocost: avoid out of bounds shift UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures. [ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020 Call Trace: dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80 __run_timer_base+0x1b6/0x250 ... Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large. I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36917
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: block: fix overflow in blk_ioctl_discard() There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now.

Published: 2024-05-30Modified: 2025-09-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36918
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Check bloom filter map value size This patch adds a missing check to bloom filter creating, rejecting values above KMALLOC_MAX_SIZE. This brings the bloom map in line with many other map types. The lack of this protection can cause kernel crashes for value sizes that overflow int's. Such a crash was caught by syzkaller. The next patch adds more guard-rails at a lower level.

Published: 2024-05-30Modified: 2025-09-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36919
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload The session resources are used by FW and driver when session is offloaded, once session is uploaded these resources are not used. The lock is not required as these fields won't be used any longer. The offload and upload calls are sequential, hence lock is not required. This will suppress following BUG_ON(): [ 449.843143] ------------[ cut here ]------------ [ 449.848302] kernel BUG at mm/vmalloc.c:2727! [ 449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1 Rebooting. [ 449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016 [ 449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc] [ 449.882910] RIP: 0010:vunmap+0x2e/0x30 [ 449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41 [ 449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206 [ 449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005 [ 449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000 [ 449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf [ 449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000 [ 449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0 [ 449.953701] FS: 0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000 [ 449.962732] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0 [ 449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 449.993028] Call Trace: [ 449.995756] __iommu_dma_free+0x96/0x100 [ 450.000139] bnx2fc_free_session_resc+0x67/0x240 [bnx2fc] [ 450.006171] bnx2fc_upload_session+0xce/0x100 [bnx2fc] [ 450.011910] bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc] [ 450.018136] fc_rport_work+0x103/0x5b0 [libfc] [ 450.023103] process_one_work+0x1e8/0x3c0 [ 450.027581] worker_thread+0x50/0x3b0 [ 450.031669] ? rescuer_thread+0x370/0x370 [ 450.036143] kthread+0x149/0x170 [ 450.039744] ? set_kthread_struct+0x40/0x40 [ 450.044411] ret_from_fork+0x22/0x30 [ 450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls [ 450.048497] libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler [ 450.159753] ---[ end trace 712de2c57c64abc8 ]---

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36920
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Avoid memcpy field-spanning write WARNING When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver prints this WARNING message: memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf->reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1) WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr] The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8 replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended to be a flexible length array, so the WARN is a false positive. To suppress the WARN, remove the constant number '1' from the array declaration and clarify that it has flexible length. Also, adjust the memory allocation size to match the change.

Published: 2024-05-30Modified: 2025-10-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36921
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: guard against invalid STA ID on removal Guard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would result in out-of-bounds array accesses. This prevents issues should the driver get into a bad state during error handling.

Published: 2024-05-30Modified: 2025-03-01
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36922
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock.

Published: 2024-05-30Modified: 2025-10-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36924
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up() lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock.

Published: 2024-05-30Modified: 2025-01-10
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36926
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: LPAR panics during boot up with a frozen PE At the time of LPAR boot up, partition firmware provides Open Firmware property ibm,dma-window for the PE. This property is provided on the PCI bus the PE is attached to. There are execptions where the partition firmware might not provide this property for the PE at the time of LPAR boot up. One of the scenario is where the firmware has frozen the PE due to some error condition. This PE is frozen for 24 hours or unless the whole system is reinitialized. Within this time frame, if the LPAR is booted, the frozen PE will be presented to the LPAR but ibm,dma-window property could be missing. Today, under these circumstances, the LPAR oopses with NULL pointer dereference, when configuring the PCI bus the PE is attached to. BUG: Kernel NULL pointer dereference on read at 0x000000c8 Faulting instruction address: 0xc0000000001024c0 Oops: Kernel access of bad area, sig: 7 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: Supported: Yes CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.4.0-150600.9-default #1 Hardware name: IBM,9043-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_023) hv:phyp pSeries NIP: c0000000001024c0 LR: c0000000001024b0 CTR: c000000000102450 REGS: c0000000037db5c0 TRAP: 0300 Not tainted (6.4.0-150600.9-default) MSR: 8000000002009033 CR: 28000822 XER: 00000000 CFAR: c00000000010254c DAR: 00000000000000c8 DSISR: 00080000 IRQMASK: 0 ... NIP [c0000000001024c0] pci_dma_bus_setup_pSeriesLP+0x70/0x2a0 LR [c0000000001024b0] pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 Call Trace: pci_dma_bus_setup_pSeriesLP+0x60/0x2a0 (unreliable) pcibios_setup_bus_self+0x1c0/0x370 __of_scan_bus+0x2f8/0x330 pcibios_scan_phb+0x280/0x3d0 pcibios_init+0x88/0x12c do_one_initcall+0x60/0x320 kernel_init_freeable+0x344/0x3e4 kernel_init+0x34/0x1d0 ret_from_kernel_user_thread+0x14/0x1c

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36927
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix uninit-value access in __ip_make_skb() KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL while __ip_make_skb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN. Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL on the socket. Also, fl4->fl4_icmp_type and fl4->fl4_icmp_code are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4_init_output(), but we should not rely on specific union layout. Initialize these explicitly in raw_sendmsg(). [1] BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 ip_finish_skb include/net/ip.h:243 [inline] ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508 raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128 ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365 raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014

Published: 2024-05-30Modified: 2026-01-19
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36928
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Fix kernel panic after setting hsuid Symptom: When the hsuid attribute is set for the first time on an IQD Layer3 device while the corresponding network interface is already UP, the kernel will try to execute a napi function pointer that is NULL. Example: --------------------------------------------------------------------------- [ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP [ 2057.572702] Modules linked in: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev vfio_iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 bridge stp llc dasd_eckd_mod qeth dasd_mod qdio ccwgroup pkey zcrypt [ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1 [ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR) [ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [ 2057.572754] 00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.572758] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [ 2057.572762] Krnl Code:#0000000000000000: 0000 illegal >0000000000000002: 0000 illegal 0000000000000004: 0000 illegal 0000000000000006: 0000 illegal 0000000000000008: 0000 illegal 000000000000000a: 0000 illegal 000000000000000c: 0000 illegal 000000000000000e: 0000 illegal [ 2057.572800] Call Trace: [ 2057.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398 [ 2057.572809] [<0000000091515f76>] __do_softirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58 [ 2057.572817] ([<0000000090d2cbd6>] do_softirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60>] __local_bh_enable_ip+0x80/0x98 [ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] afiucv_hs_send+0x24e/0x300 [af_iucv] [ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv] [ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv] [ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8 [ 2057.572839] [<00000000912e9580>] sys_socketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a>] system_call+0x2a6/0x2c8 [ 2057.572843] Last Breaking-Event-Address: [ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt ------------------------------------------------------------------------------------------- Analysis: There is one napi structure per out_q: card->qdio.out_qs[i].napi The napi.poll functions are set during qeth_open(). Since commit 1cfef80d4c2b ("s390/qeth: Don't call dev_close/dev_open (DOWN/UP)") qeth_set_offline()/qeth_set_online() no longer call dev_close()/ dev_open(). So if qeth_free_qdio_queues() cleared card->qdio.out_qs[i].napi.poll while the network interface was UP and the card was offline, they are not set again. Reproduction: chzdev -e $devno layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncated---

Published: 2024-05-30Modified: 2025-04-01
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36929
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: core: reject skb_copy(_expand) for fraglist GSO skbs SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skb_copy or skb_copy_expand, in order to prevent a crash on a potential later call to skb_gso_segment.

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36930
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: fix null pointer dereference within spi_sync If spi_sync() is called with the non-empty queue and the same spi_message is then reused, the complete callback for the message remains set while the context is cleared, leading to a null pointer dereference when the callback is invoked from spi_finalize_current_message(). With function inlining disabled, the call stack might look like this: _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474 spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230 __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4 __spi_transfer_message_noqueue from __spi_sync+0x204/0x248 __spi_sync from spi_sync+0x24/0x3c spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd] mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154 _regmap_raw_read from _regmap_bus_read+0x44/0x70 _regmap_bus_read from _regmap_read+0x60/0xd8 _regmap_read from regmap_read+0x3c/0x5c regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x118/0x1f4 irq_thread from kthread+0xd8/0xf4 kthread from ret_from_fork+0x14/0x28 Fix this by also setting message->complete to NULL when the transfer is complete.

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36931
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: s390/cio: Ensure the copied buf is NUL terminated Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from userspace to that buffer. Later, we use scanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using scanf. Fix this issue by using memdup_user_nul instead.

Published: 2024-05-30Modified: 2025-01-15
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36933
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment(). syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls skb_mac_gso_segment() to invoke inner protocol GSO handlers. nsh_gso_segment() does the following for the original skb before calling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up skb->mac_len and skb->protocol for the inner protocol. and does the following for the segmented skb 6. set ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header + mac_len to skb->network_header 10. restore skb->mac_len There are two problems in 6-7 and 8-9. (a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the middle of the outer header. It seems nsh_gso_segment() has never worked with outer headers so far. At the end of nsh_gso_segment(), the outer header must be restored for the segmented skb, instead of the NSH header. To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,mac_header,protocol} properly. [0]: BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __ ---truncated---

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36934
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bna: ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user.

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36937
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xdp: use flags field to disambiguate broadcast redirect When redirecting a packet using XDP, the bpf_redirect_map() helper will set up the redirect destination information in struct bpf_redirect_info (using the __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect() function will read this information after the XDP program returns and pass the frame on to the right redirect destination. When using the BPF_F_BROADCAST flag to do multicast redirect to a whole map, __bpf_xdp_redirect_map() sets the 'map' pointer in struct bpf_redirect_info to point to the destination map to be broadcast. And xdp_do_redirect() reacts to the value of this map pointer to decide whether it's dealing with a broadcast or a single-value redirect. However, if the destination map is being destroyed before xdp_do_redirect() is called, the map pointer will be cleared out (by bpf_clear_redirect_map()) without waiting for any XDP programs to stop running. This causes xdp_do_redirect() to think that the redirect was to a single target, but the target pointer is also NULL (since broadcast redirects don't have a single target), so this causes a crash when a NULL pointer is passed to dev_map_enqueue(). To fix this, change xdp_do_redirect() to react directly to the presence of the BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info to disambiguate between a single-target and a broadcast redirect. And only read the 'map' pointer if the broadcast flag is set, aborting if that has been cleared out in the meantime. This prevents the crash, while keeping the atomic (cmpxchg-based) clearing of the map pointer itself, and without adding any more checks in the non-broadcast fast path.

Published: 2024-05-30Modified: 2025-09-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36938
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1]. [1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 value changed: 0xffffffff83d7feb0 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);". To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend.

Published: 2024-05-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36939
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfs: Handle error of rpc_proc_register() in nfs_net_init(). syzkaller reported a warning [0] triggered while destroying immature netns. rpc_proc_register() was called in init_nfs_fs(), but its error has been ignored since at least the initial commit 1da177e4c3f4 ("Linux-2.6.12-rc2"). Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces") converted the procfs to per-netns and made the problem more visible. Even when rpc_proc_register() fails, nfs_net_init() could succeed, and thus nfs_net_exit() will be called while destroying the netns. Then, remove_proc_entry() will be called for non-existing proc directory and trigger the warning below. Let's handle the error of rpc_proc_register() properly in nfs_net_init(). [0]: name 'nfs' WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Modules linked in: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8 FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170 setup_net+0x46c/0x660 net/core/net_namespace.c:372 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ksys_unshare+0x342/0x760 kernel/fork.c:3322 __do_sys_unshare kernel/fork.c:3393 [inline] __se_sys_unshare kernel/fork.c:3391 [inline] __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000

Published: 2024-05-30Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36940
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: pinctrl: core: delete incorrect free in pinctrl_enable() The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead to a double free. The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as well.

Published: 2024-05-30Modified: 2025-01-10
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36941
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: don't free NULL coalescing rule If the parsing fails, we can dereference a NULL pointer here.

Published: 2024-05-30Modified: 2025-05-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36945
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/smc: fix neighbour and rtable leak in smc_ib_find_route() In smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable resolved by ip_route_output_flow() are not released or put before return. It may cause the refcount leak, so fix it.

Published: 2024-05-30Modified: 2025-09-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36946
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: phonet: fix rtm_phonet_notify() skb allocation fill_route() stores three components in the skb: - struct rtmsg - RTA_DST (u8) - RTA_OIF (u32) Therefore, rtm_phonet_notify() should use NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(1) + nla_total_size(4)

Published: 2024-05-30Modified: 2026-01-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36947
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: qibfs: fix dentry leak simple_recursive_removal() drops the pinning references to all positives in subtree. For the cases when its argument has been kept alive by the pinning alone that's exactly the right thing to do, but here the argument comes from dcache lookup, that needs to be balanced by explicit dput(). Fucked-up-by: Al Viro

Published: 2024-05-30Modified: 2025-09-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36949
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: amd/amdkfd: sync all devices to wait all processes being evicted If there are more than one device doing reset in parallel, the first device will call kfd_suspend_all_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.

Published: 2024-05-30Modified: 2025-10-01
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36950
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: firewire: ohci: mask bus reset interrupts between ISR and bottom half In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until bus_reset_work has serviced and cleared the interrupt. Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them. irq_handler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irq_handler, because we won't service the event until later. irq_handler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irq_handler being called again each time it exits. This freeze can be reproduced by loading firewire_ohci with "modprobe firewire_ohci debug=-1" (to enable all debugging output). Apparently there are also some cases where bus_reset_work will get called soon enough to clear the event, and operation will continue normally. This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization. irq_handler will now leave the event flag set but mask bus reset interrupts, so irq_handler won't be called again and there will be no freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired. As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after bus_reset_work has executed.

Published: 2024-05-30Modified: 2025-12-17
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36951
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: range check cp bad op exception interrupts Due to a CP interrupt bug, bad packet garbage exception codes are raised. Do a range check so that the debugger and runtime do not receive garbage codes. Update the user api to guard exception code type checking as well.

Published: 2024-05-30Modified: 2025-10-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36952
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up There are cases after NPIV deletion where the fabric switch still believes the NPIV is logged into the fabric. This occurs when a vport is unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the fabric. Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including the fabric D_ID, removes the last ndlp reference and frees the ndlp rport object. This sometimes causes the race condition where the final DA_ID and LOGO are skipped from being sent to the fabric switch. Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID and LOGO are sent.

Published: 2024-05-30Modified: 2025-10-01
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36953
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr() vgic_v2_parse_attr() is responsible for finding the vCPU that matches the user-provided CPUID, which (of course) may not be valid. If the ID is invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handled gracefully. Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id() actually returns something and fail the ioctl if not.

Published: 2024-05-30Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36954
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tipc: fix a possible memleak in tipc_buf_append __skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path.

Published: 2024-05-30Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36955
HIGH7.7

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node() The documentation for device_get_named_child_node() mentions this important point: " The caller is responsible for calling fwnode_handle_put() on the returned fwnode pointer. " Add fwnode_handle_put() to avoid a leaked reference.

Published: 2024-05-30Modified: 2025-04-01
CVSS 3.xHIGH 7.7
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36957
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: avoid off-by-one read from userspace We try to access count + 1 byte from userspace with memdup_user(buffer, count + 1). However, the userspace only provides buffer of count bytes and only these count bytes are verified to be okay to access. To ensure the copied buffer is NUL terminated, we use memdup_user_nul instead.

Published: 2024-05-30Modified: 2025-12-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36959
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map() If we fail to allocate propname buffer, we need to drop the reference count we just took. Because the pinctrl_dt_free_maps() includes the droping operation, here we call it directly.

Published: 2024-05-30Modified: 2025-01-14
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36960
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix invalid reads in fence signaled events Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads.

Published: 2024-06-03Modified: 2025-04-01
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-36964
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs/9p: only translate RWX permissions for plain 9P2000 Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.

Published: 2024-06-03Modified: 2025-12-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36965
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: remoteproc: mediatek: Make sure IPI buffer fits in L2TCM The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well. Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic. To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core).

Published: 2024-06-08Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36967
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak in tpm2_key_encode() 'scratch' is never freed. Fix this by calling kfree() in the success, and in the error case.

Published: 2024-06-08Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36968
MEDIUM6.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range. Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value. divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in: ---[ end trace 0000000000000000 ]---

Published: 2024-06-08Modified: 2024-11-21
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H
References
CVE-2024-36969
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix division by zero in setup_dsc_config When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113.

Published: 2024-06-08Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36971
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: fix __dst_negative_advice() race __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF. RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst). Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order. Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves. Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks. Many thanks to Clement Lecigne for tracking this issue. This old bug became visible after the blamed commit, using UDP sockets.

Published: 2024-06-10Modified: 2025-11-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36973
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe() When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function gp_auxiliary_device_release() calls ida_free() and kfree(aux_device_wrapper) to free memory. We should't call them again in the error handling path. Fix this by skipping the redundant cleanup functions.

Published: 2024-06-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36974
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided, taprio_parse_mqprio_opt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called. First call (with valid attributes) sets dev->num_tc to a non zero value. Second call (with arbitrary mqprio attributes) returns early from taprio_parse_mqprio_opt() and bad things can happen.

Published: 2024-06-18Modified: 2025-10-01
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36975
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Do not use WARN when encode fails When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information.

Published: 2024-06-18Modified: 2025-10-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36977
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Wait unconditionally after issuing EndXfer command Currently all controller IP/revisions except DWC3_usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions >= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed. Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests. Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally.

Published: 2024-06-18Modified: 2025-10-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-36978
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: sched: sch_multiq: fix possible OOB write in multiq_tune() q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur.

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-36979
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: bridge: mst: fix vlan use-after-free syzbot reported a suspicious rcu usage[1] in bridge's mst code. While fixing it I noticed that nothing prevents a vlan to be freed while walking the list from the same path (br forward delay timer). Fix the rcu usage and also make sure we are not accessing freed memory by making br_mst_vlan_set_state use rcu read lock. [1] WARNING: suspicious RCU usage 6.9.0-rc6-syzkaller #0 Not tainted ----------------------------- net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage! ... stack backtrace: CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nbp_vlan_group net/bridge/br_private.h:1599 [inline] br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105 br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47 br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88 call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429 run_timer_base kernel/time/timer.c:2438 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448 __do_softirq+0x2c6/0x980 kernel/softirq.c:554 invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633 irq_exit_rcu+0x9/0x30 kernel/softirq.c:645 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758 Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25 RSP: 0018:ffffc90013657100 EFLAGS: 00000206 RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001 RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60 RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0 R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28 R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-37021
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fpga: manager: add owner module and take its refcount The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga manager. Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions.

Published: 2024-06-24Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-37078
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential kernel bug due to lack of writeback flag waiting Destructive writes to a block device on which nilfs2 is mounted can cause a kernel bug in the folio/page writeback start routine or writeback end routine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 This is because when the log writer starts a writeback for segment summary blocks or a super root block that use the backing device's page cache, it does not wait for the ongoing folio/page writeback, resulting in an inconsistent writeback state. Fix this issue by waiting for ongoing writebacks when putting folios/pages on the backing device into writeback state.

Published: 2024-06-25Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-37354
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix crash on racing fsync and size-extending write into prealloc We have been seeing crashes on duplicate keys in btrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs] With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121) So we're logging a changed extent from fsync, which is splitting an extent in the log tree. But this split part already exists in the tree, triggering the BUG(). This is the state of the log tree at the time of the crash, dumped with drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py) to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ... So the real problem happened earlier: notice that items 4 (4k-12k) and 5 (8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and item 5 starts at i_size. Here is the state of ---truncated---

Published: 2024-06-25Modified: 2025-12-06
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-37356
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tcp: Fix shift-out-of-bounds in dctcp_update_alpha(). In dctcp_update_alpha(), we use a module parameter dctcp_shift_g as follows: alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... delivered_ce <<= (10 - dctcp_shift_g); It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Let's limit the max value of dctcp_shift_g by param_set_uint_minmax(). With this patch: # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: write error: Invalid argument [0]: UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12 shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [inline] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [inline] sock_close+0xc0/0x240 net/socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x9c8/0x2540 kernel/exit.c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [inline] __se_sys_exit_group kernel/exit.c:1036 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38388
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed. The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers.

Published: 2024-06-21Modified: 2025-04-01
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-38390
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Patchwork: https://patchwork.freedesktop.org/patch/588919/

Published: 2024-06-21Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38538
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: net: bridge: xmit: make sure we have at least eth header len bytes syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-38540
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0. In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called. roundup_pow_of_two is documented as undefined for 0. Fix it in the one caller that had this combination. The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re] ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core] ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_core] ib_register_device+0x53c/0x630 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] auxiliary_bus_probe+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 really_probe+0xde/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit_module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode_prepare+0x149/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode+0x75/0x230 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x8e/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __count_memcg_events+0x69/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events.constprop.0+0x1a/0x30 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1f0/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x34e/0x640 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60 ---[ end trace ]---

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38541
CRITICAL9.8

In the Linux kernel, the following vulnerability has been resolved: of: module: add buffer overflow check in of_modalias() In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38543
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure The kcalloc() in dmirror_device_evict_chunk() will return null if the physical memory has run out. As a result, if src_pfns or dst_pfns is dereferenced, the null pointer dereference bug will happen. Moreover, the device is going away. If the kcalloc() fails, the pages mapping a chunk could not be evicted. So add a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, Switch kcalloc() to kvcalloc() in order to avoid failing allocations.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38544
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale. This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed.

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-38545
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix UAF for cq async event The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF. Use the xa_lock() to protect the CQ refcount.

Published: 2024-06-19Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38546
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm: vc4: Fix possible null pointer dereference In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38547
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered.

Published: 2024-06-19Modified: 2025-09-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38548
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode.

Published: 2024-06-19Modified: 2025-04-01
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38549
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add 0 size check to mtk_drm_gem_obj Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38550
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: ASoC: kirkwood: Fix potential NULL dereference In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if CONFIG_PLAT_ORION macro is not defined. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-06-19Modified: 2025-04-01
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38552
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential index out of bounds in color transformation function Fixes index out of bounds issue in the color transformation function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, an error message is logged and the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38553
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38554
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ax25: Fix reference count leak issue of net_device There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak. In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38555
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Discard command completions in internal error Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually. Kernel log: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Call Trace: ? __warn+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0xa0 common_interrupt+0x7b/0xa0 asm_common_interrupt+0x22/0x40

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38556
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Add a timeout to acquire the command queue semaphore Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion. Kernel log example: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion

Published: 2024-06-19Modified: 2025-03-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38557
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Reload only IB representors upon lag disable/enable On lag disable, the bond IB device along with all of its representors are destroyed, and then the slaves' representors get reloaded. In case the slave IB representor load fails, the eswitch error flow unloads all representors, including ethernet representors, where the netdevs get detached and removed from lag bond. Such flow is inaccurate as the lag driver is not responsible for loading/unloading ethernet representors. Furthermore, the flow described above begins by holding lag lock to prevent bond changes during disable flow. However, when reaching the ethernet representors detachment from lag, the lag lock is required again, triggering the following deadlock: Call trace: __switch_to+0xf4/0x148 __schedule+0x2c8/0x7d0 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x28 __mutex_lock.isra.13+0x2b8/0x570 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x4c/0x68 mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core] mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core] mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core] mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core] mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core] mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core] mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core] mlx5_disable_lag+0x130/0x138 [mlx5_core] mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core] devlink_nl_cmd_eswitch_set_doit+0xdc/0x180 genl_family_rcv_msg_doit.isra.17+0xe8/0x138 genl_rcv_msg+0xe4/0x220 netlink_rcv_skb+0x44/0x108 genl_rcv+0x40/0x58 netlink_unicast+0x198/0x268 netlink_sendmsg+0x1d4/0x418 sock_sendmsg+0x54/0x60 __sys_sendto+0xf4/0x120 __arm64_sys_sendto+0x30/0x40 el0_svc_common+0x8c/0x120 do_el0_svc+0x30/0xa0 el0_svc+0x20/0x30 el0_sync_handler+0x90/0xb8 el0_sync+0x160/0x180 Thus, upon lag enable/disable, load and unload only the IB representors of the slaves preventing the deadlock mentioned above. While at it, refactor the mlx5_esw_offloads_rep_load() function to have a static helper method for its internal logic, in symmetry with the representor unload design.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38558
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix overwriting ct original tuple for ICMPv6 OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38559
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Ensure the copied buf is NUL terminated Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38560
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-38561
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: kunit: Fix kthread reference There is a race condition when a kthread finishes after the deadline and before the call to kthread_stop(), which may lead to use after free.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38564
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks.

Published: 2024-06-19Modified: 2025-10-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38565
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: ar5523: enable proper endpoint verification Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38567
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: add a proper sanity check for endpoints Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 [2] Related syzkaller crashes:

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38568
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the memory write overflow of event_group array occurs. Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds. There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38569
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write overflow of event_group array occurs. Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds. There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38570
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38571
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tsens: Fix null pointer dereference compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c) as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null pointer dereference (if DEBUG or DYNAMIC_DEBUG set). Fix this bug by adding null pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38573
HIGH7.5

In the Linux kernel, the following vulnerability has been resolved: cppc_cpufreq: Fix possible null pointer dereference cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from different places with various parameters. So cpufreq_cpu_get() can return null as 'policy' in some circumstances. Fix this bug by adding null return check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-06-19Modified: 2025-04-01
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38575
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: pcie: handle randbuf allocation failure The kzalloc() in brcmf_pcie_download_fw_nvram() will return null if the physical memory has run out. As a result, if we use get_random_bytes() to generate random bytes in the randbuf, the null pointer dereference bug will happen. In order to prevent allocation failure, this patch adds a separate function using buffer on kernel stack to generate random bytes in the randbuf, which could prevent the kernel stack from overflow.

Published: 2024-06-19Modified: 2025-01-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38576
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: rcu: Fix buffer overflow in print_cpu_stall_info() The rcuc-starvation output from print_cpu_stall_info() might overflow the buffer if there is a huge difference in jiffies difference. The situation might seem improbable, but computers sometimes get very confused about time, which can result in full-sized integers, and, in this case, buffer overflow. Also, the unsigned jiffies difference is printed using %ld, which is normally for signed integers. This is intentional for debugging purposes, but it is not obvious from the code. This commit therefore changes sprintf() to snprintf() and adds a clarifying comment about intention of %ld format. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-06-19Modified: 2025-04-01
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-38577
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38578
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ecryptfs: Fix buffer size for tag 66 packet The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and write_tag_66_packet() will write up to 3 bytes past the end of the buffer. Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer. This fixes the below kasan slab-out-of-bounds bug: BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181 CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: dump_stack_lvl+0x4c/0x70 print_report+0xc5/0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? kasan_complete_mode_report_info+0x44/0x210 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 __asan_store1+0x62/0x80 ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10 ? __alloc_pages+0x2e2/0x540 ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d] ? dentry_open+0x8f/0xd0 ecryptfs_write_metadata+0x30a/0x550 ? __pfx_ecryptfs_write_metadata+0x10/0x10 ? ecryptfs_get_lower_file+0x6b/0x190 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 ? __pfx_path_openat+0x10/0x10 do_filp_open+0x15e/0x290 ? __pfx_do_filp_open+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? _raw_spin_lock+0x86/0xf0 ? __pfx__raw_spin_lock+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? alloc_fd+0xf4/0x330 do_sys_openat2+0x122/0x160 ? __pfx_do_sys_openat2+0x10/0x10 __x64_sys_openat+0xef/0x170 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f00a703fd67 Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 Allocated by task 181: kasan_save_stack+0x2f/0x60 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x25/0x40 __kasan_kmalloc+0xc5/0xd0 __kmalloc+0x66/0x160 ecryptfs_generate_key_packet_set+0x6d2/0xde0 ecryptfs_write_metadata+0x30a/0x550 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 do_filp_open+0x15e/0x290 do_sys_openat2+0x122/0x160 __x64_sys_openat+0xef/0x170 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38579
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: bcm - Fix pointer arithmetic In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38580
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: epoll: be better about file lifetimes epoll can call out to vfs_poll() with a file pointer that may race with the last 'fput()'. That would make f_count go down to zero, and while the ep->mtx locking means that the resulting file pointer tear-down will be blocked until the poll returns, it means that f_count is already dead, and any use of it won't actually get a reference to the file any more: it's dead regardless. Make sure we have a valid ref on the file pointer before we call down to vfs_poll() from the epoll routines.

Published: 2024-06-19Modified: 2025-10-20
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38581
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/mes: fix use-after-free issue Delete fence fallback timer to fix the ramdom use-after-free issue. v2: move to amdgpu_mes.c

Published: 2024-06-19Modified: 2025-05-27
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38582
MEDIUM5.3

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential hang in nilfs_detach_log_writer() Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount. Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below: nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK *** Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates. The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy().

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.3
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-38583
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free of timer for log writer thread Patch series "nilfs2: fix log writer related issues". This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log. This patch (of 3): A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38585
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: tools/nolibc/stdlib: fix memory error in realloc() Pass user_p_len to memcpy() instead of heap->len to prevent realloc() from copying an extra sizeof(heap) bytes from beyond the allocated region.

Published: 2024-06-19Modified: 2025-09-17
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-38586
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: r8169: Fix possible ring buffer corruption on fragmented Tx packets. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied.

Published: 2024-06-19Modified: 2025-09-17
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38588
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix possible use-after-free issue in ftrace_location() KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause is that, in lookup_rec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free! To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().

Published: 2024-06-19Modified: 2025-12-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38589
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netrom: fix possible dead-lock in nr_rt_ioctl() syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1] Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node) [1] WARNING: possible circular locking dependency detected 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted ------------------------------------------------------ syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK *** 1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70 ---truncated---

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38590
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Modify the print level of CQE error Too much print may lead to a panic in kernel. Change ibdev_err() to ibdev_err_ratelimited(), and change the printing level of cqe dump to debug level.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38591
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix deadlock on SRQ async events. xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock.

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38594
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: stmmac: move the EST lock to struct stmmac_priv Reinitialize the whole EST structure would also reset the mutex lock which is embedded in the EST structure, and then trigger the following warning. To address this, move the lock to struct stmmac_priv. We also need to reacquire the mutex lock when doing this initialization. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c

Published: 2024-06-19Modified: 2025-10-31
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38596
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg A data-race condition has been identified in af_unix. In one data path, the write function unix_release_sock() atomically writes to sk->sk_shutdown using WRITE_ONCE. However, on the reader side, unix_stream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03 The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7"). Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.") addressed a comparable issue in the past regarding sk->sk_shutdown. However, it overlooked resolving this particular data path. This patch only offending unix_stream_sendmsg() function, since the other reads seem to be protected by unix_state_lock() as discussed in

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38597
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38598
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: md: fix resync softlockup when bitmap size is less than array size Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup: kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30 And the detailed process is as follows: md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks. Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be. Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38599
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: jffs2: prevent xattr node from overflowing the eraseblock Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker. Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as: jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead This breaks the filesystem and can lead to KASAN crashes such as: BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-38600
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ALSA: Fix deadlocks with kctl removals at disconnection In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38601
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix a race between readers and resize checks The reader code in rb_get_reader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer. The resize operation in ring_buffer_resize() can be invoked in parallel. It calls rb_check_pages() which can detect the described inconsistency and stop further tracing: [ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] tracing_entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] [ 190.272414] ---[ end trace 0000000000000000 ]--- Note that ring_buffer_resize() calls rb_check_pages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue. The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rb_get_reader_page(): ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (!ret) goto spin; for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */ __asm__ __volatile__ ("" : : : "memory"); rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list; .. ---truncated---

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38602
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ax25: Fix reference count leak issues of ax25_dev The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the issue of ax25_dev_device_down(), increase the reference count of ax25_dev once in ax25_dev_device_up() and decrease the reference count of ax25_dev after it is removed from the ax25_dev_list.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38603
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset() pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action() fails, the irq vector is not freed, which leads to a memory leak. Replace the devm_add_action with devm_add_action_or_reset to ensure the irq vector can be destroyed when it fails.

Published: 2024-06-19Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38605
HIGH8.8

In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix NULL module pointer assignment at card init The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare.

Published: 2024-06-19Modified: 2025-04-01
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38607
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization.

Published: 2024-06-19Modified: 2025-10-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38610
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes". Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks. Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte(). This patch (of 3): We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage. (1) We're not checking PTE write permissions. Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now. (2) We're not rejecting refcounted pages. As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. Let's make sure to reject them. (3) We are only looking at the first PTE of a bigger range. We only lookup a single PTE, but memmap->len may span a larger area. Let's loop over all involved PTEs and make sure the PFN range is actually contiguous. Reject everything else: it couldn't have worked either way, and rather made use access PFNs we shouldn't be accessing.

Published: 2024-06-19Modified: 2025-09-17
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38611
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: i2c: et8ek8: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=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/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text)

Published: 2024-06-19Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38612
CRITICAL9.8

In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38613
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: m68k: Fix spinlock race in kernel thread creation Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch. This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register. The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()). A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck. As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit. Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). Disable interrupts temporarily when switching the tasks' register sets in resume(). Note that a simple oriw 0x700,%sr after restoring sr is not enough here - this leaves enough of a race for the 'spinlock recursion' warning to still be observed. Tested on ARAnyM and qemu (Quadra 800 emulation).

Published: 2024-06-19Modified: 2025-09-17
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38615
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cpufreq: exit() callback is optional The exit() callback is optional and shouldn't be called without checking a valid pointer first. Also, we must clear freq_table pointer even if the exit() callback isn't present.

Published: 2024-06-19Modified: 2025-10-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38616
HIGH8.2

In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: re-fix fortified-memset warning The carl9170_tx_release() function sometimes triggers a fortified-memset warning in my randconfig builds: In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortify_memset_chk', inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'kref_put' at include/linux/kref.h:65:3, inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 493 | __write_overflow_field(p_size_field, size); Kees previously tried to avoid this by using memset_after(), but it seems this does not fully address the problem. I noticed that the memset_after() here is done on a different part of the union (status) than the original cast was from (rate_driver_data), which may confuse the compiler. Unfortunately, the memset_after() trick does not work on driver_rates[] because that is part of an anonymous struct, and I could not get struct_group() to do this either. Using two separate memset() calls on the two members does address the warning though.

Published: 2024-06-19Modified: 2025-04-01
CVSS 3.xHIGH 8.2
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
References
CVE-2024-38618
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ALSA: timer: Set lower bound of start tick time Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow.

Published: 2024-06-19Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38619
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb-storage: alauda: Check whether the media is initialized The member "uzonesize" of struct alauda_info will remain 0 if alauda_init_media() fails, potentially causing divide errors in alauda_read_data() and alauda_write_lba(). - Add a member "media_initialized" to struct alauda_info. - Change a condition in alauda_check_media() to ensure the first initialization. - Add an error check for the return value of alauda_init_media().

Published: 2024-06-20Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38620
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HCI: Remove HCI_AMP support Since BT_HS has been remove HCI_AMP controllers no longer has any use so remove it along with the capability of creating AMP controllers. Since we no longer need to differentiate between AMP and Primary controllers, as only HCI_PRIMARY is left, this also remove hdev->dev_type altogether.

Published: 2024-06-20Modified: 2025-10-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38621
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: media: stk1160: fix bounds checking in stk1160_copy_video() The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true. Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". Instead, the math to calculate the destination where we are writing is a bit involved. You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line. To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return. Otherwise, write up to buf->length bytes.

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-38622
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Add callback function pointer check before its call In dpu_core_irq_callback_handler() callback function pointer is compared to NULL, but then callback function is unconditionally called by this pointer. Fix this bug by adding conditional return. Found by Linux Verification Center (linuxtesting.org) with SVACE. Patchwork: https://patchwork.freedesktop.org/patch/588237/

Published: 2024-06-21Modified: 2025-09-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38623
CRITICAL9.8

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Use variable length array instead of fixed size Should fix smatch warning: ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256)

Published: 2024-06-21Modified: 2025-03-24
CVSS 3.xCRITICAL 9.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38624
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow For example, in the expression: vbo = 2 * vbo + skip

Published: 2024-06-21Modified: 2025-10-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38625
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check 'folio' pointer for NULL It can be NULL if bmap is called.

Published: 2024-06-21Modified: 2025-01-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38627
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: stm class: Fix a double free in stm_register_device() The put_device(&stm->dev) call will trigger stm_device_release() which frees "stm" so the vfree(stm) on the next line is a double free.

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38628
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind. Hang on to the control IDs instead of pointers since those are correctly handled with locks.

Published: 2024-06-21Modified: 2025-03-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38630
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released.

Published: 2024-06-21Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38633
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Update uart_driver_registered on driver removal The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call.

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38634
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Lock port->lock when calling uart_handle_cts_change() uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38635
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: soundwire: cadence: fix invalid PDI offset For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT. This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds. A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well. A follow-up patch completely removes this useless offset.

Published: 2024-06-21Modified: 2025-09-17
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-38636
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: multidev: fix to recognize valid zero block address As reported by Yi Zhang in mailing list [1], kernel warning was catched during zbd/010 test as below: ./check zbd/010 zbd/010 (test gap zone support with F2FS) [failed] runtime ... 3.752s something found in dmesg: [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13 [ 4378.192349] null_blk: module loaded [ 4378.209860] null_blk: disk nullb0 created [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520] dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20 [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device ... (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg' WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Call Trace: __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Shinichiro Kawasaki helps to analyse this issue and proposes a potential fixing patch in [2]. Quoted from reply of Shinichiro Kawasaki: "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a look in the commit, but it looks fine to me. So I thought the cause is not in the commit diff. I found the WARN is printed when the f2fs is set up with multiple devices, and read requests are mapped to the very first block of the second device in the direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached() modify map->m_pblk as the physical block address from each block device. It becomes zero when it is mapped to the first block of the device. However, f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the whole f2fs, across the all block devices. It compares map->m_pblk against NULL_ADDR == 0, then go into the unexpected branch and sets the invalid iomap->length. The WARN catches the invalid iomap->length. This WARN is printed even for non-zoned block devices, by following steps. - Create two (non-zoned) null_blk devices memory backed with 128MB size each: nullb0 and nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mount_dir}" # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192 # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct ..." So, the root cause of this issue is: when multi-devices feature is on, f2fs_map_blocks() may return zero blkaddr in non-primary device, which is a verified valid block address, however, f2fs_iomap_begin() treats it as an invalid block address, and then it triggers the warning in iomap framework code. Finally, as discussed, we decide to use a more simple and direct way that checking (map.m_flags & F2FS_MAP_MAPPED) condition instead of (map.m_pblk != NULL_ADDR) to fix this issue. Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this issue. [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/

Published: 2024-06-21Modified: 2025-10-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38637
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: greybus: lights: check return of get_channel_from_mode If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38659
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: enic: Validate length of nl attributes in enic_set_vf_port enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enic_set_vf_port expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enic_set_vf_port.

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-38661
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: s390/ap: Fix crash in AP internal function modify_bitmap() A system crash like this Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oops occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX. The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow.

Published: 2024-06-25Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-38662
MEDIUM4.7

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.

Published: 2024-06-21Modified: 2024-11-21
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N
References
CVE-2024-38667
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: riscv: prevent pt_regs corruption for secondary idle threads Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context.

Published: 2024-06-24Modified: 2025-05-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-38780
MEDIUM5.5

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().

Published: 2024-06-21Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39276
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find() Syzbot reports a warning as follows: ============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================ This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage. So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.

Published: 2024-06-25Modified: 2025-03-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-39277
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: handle NUMA_NO_NODE correctly cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan.c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Use cpumask_of_node() in place when binding a kernel thread to a cpuset of a particular node. Note that the provided node id is checked inside map_benchmark_ioctl(). It's just a NUMA_NO_NODE case which is not handled properly later. Found by Linux Verification Center (linuxtesting.org).

Published: 2024-06-21Modified: 2025-05-30
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-39292
MEDIUM5.5

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.

Published: 2024-06-24Modified: 2025-11-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39298
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix handling of dissolved but not taken off from buddy pages When I did memory failure tests recently, below panic occurs: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00 flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff) raw: 06fffe0000000000 dead000000000100 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000009 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(!PageBuddy(page)) ------------[ cut here ]------------ kernel BUG at include/linux/page-flags.h:1009! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__del_page_from_free_list+0x151/0x180 RSP: 0018:ffffa49c90437998 EFLAGS: 00000046 RAX: 0000000000000035 RBX: 0000000000000009 RCX: ffff8dd8dfd1c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0 RBP: ffffd901233b8000 R08: ffffffffab5511f8 R09: 0000000000008c69 R10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80 R13: 0000000000000001 R14: ffff8dd8fffc0c80 R15: 0000000000000009 FS: 00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0 Call Trace: __rmqueue_pcplist+0x23b/0x520 get_page_from_freelist+0x26b/0xe40 __alloc_pages_noprof+0x113/0x1120 __folio_alloc_noprof+0x11/0xb0 alloc_buddy_hugetlb_folio.isra.0+0x5a/0x130 __alloc_fresh_hugetlb_folio+0xe7/0x140 alloc_pool_huge_folio+0x68/0x100 set_max_huge_pages+0x13d/0x340 hugetlb_sysctl_handler_common+0xe8/0x110 proc_sys_call_handler+0x194/0x280 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xc2/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff916114887 RSP: 002b:00007ffec8a2fd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000055eae500e350 RCX: 00007ff916114887 RDX: 0000000000000004 RSI: 000055eae500e390 RDI: 0000000000000003 RBP: 000055eae50104c0 R08: 0000000000000000 R09: 000055eae50104c0 R10: 0000000000000077 R11: 0000000000000246 R12: 0000000000000004 R13: 0000000000000004 R14: 00007ff916216b80 R15: 00007ff916216a00 Modules linked in: mce_inject hwpoison_inject ---[ end trace 0000000000000000 ]--- And before the panic, there had an warning about bad page state: BUG: Bad page state in process page-types pfn:8cee00 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00 flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff) page_type: 0xffffff7f(buddy) raw: 06fffe0000000000 ffffd901241c0008 ffffd901240f8008 0000000000000000 raw: 0000000000000000 0000000000000009 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount Modules linked in: mce_inject hwpoison_inject CPU: 8 PID: 154211 Comm: page-types Not tainted 6.9.0-rc4-00499-g5544ec3178e2-dirty #22 Call Trace: dump_stack_lvl+0x83/0xa0 bad_page+0x63/0xf0 free_unref_page+0x36e/0x5c0 unpoison_memory+0x50b/0x630 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xcd/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xc2/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f189a514887 RSP: 002b:00007ffdcd899718 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f189a514887 RDX: 0000000000000009 RSI: 00007ffdcd899730 RDI: 0000000000000003 RBP: 00007ffdcd8997a0 R08: 0000000000000000 R09: 00007ffdcd8994b2 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdcda199a8 R13: 0000000000404af1 R14: 000000000040ad78 R15: 00007f189a7a5040 The root cause should be the below race: memory_failure try_memory_failure_hugetlb me_huge_page __page_handle_poison dissolve_free_hugetlb_folio drain_all_pages -- Buddy page can be isolated e.g. for compaction. take_page_off_buddy -- Failed as page is not in the ---truncated---

Published: 2024-06-25Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39301
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/9p: fix uninit-value in p9_client_rpc() Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage.

Published: 2024-06-25Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39371
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: io_uring: check for non-NULL file pointer in io_file_can_poll() In earlier kernels, it was possible to trigger a NULL pointer dereference off the forced async preparation path, if no file had been assigned. The trace leading to that looks as follows: BUG: kernel NULL pointer dereference, address: 00000000000000b0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022 RIP: 0010:io_buffer_select+0xc3/0x210 Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246 RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040 RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700 RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020 R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8 R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000 FS: 00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0 Call Trace: ? __die+0x1f/0x60 ? page_fault_oops+0x14d/0x420 ? do_user_addr_fault+0x61/0x6a0 ? exc_page_fault+0x6c/0x150 ? asm_exc_page_fault+0x22/0x30 ? io_buffer_select+0xc3/0x210 __io_import_iovec+0xb5/0x120 io_readv_prep_async+0x36/0x70 io_queue_sqe_fallback+0x20/0x260 io_submit_sqes+0x314/0x630 __do_sys_io_uring_enter+0x339/0xbc0 ? __do_sys_io_uring_register+0x11b/0xc50 ? vm_mmap_pgoff+0xce/0x160 do_syscall_64+0x5f/0x180 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x55e0a110a67e Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6 because the request is marked forced ASYNC and has a bad file fd, and hence takes the forced async prep path. Current kernels with the request async prep cleaned up can no longer hit this issue, but for ease of backporting, let's add this safety check in here too as it really doesn't hurt. For both cases, this will inevitably end with a CQE posted with -EBADF.

Published: 2024-06-25Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39463
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: 9p: add missing locking around taking dentry fid list Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it: UAF thread: refcount_t: addition on 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Freed by: p9_fid_destroy (inlined) p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 The problem is that d_fsdata was not accessed under d_lock, because d_release() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fs_remove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible.

Published: 2024-06-25Modified: 2026-01-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-39466
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/qcom/lmh: Check for SCM availability at probe Up until now, the necessary scm availability check has not been performed, leading to possible null pointer dereferences (which did happen for me on RB1). Fix that.

Published: 2024-06-25Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39467
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode() syzbot reports a kernel bug as below: F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4 ================================================================== BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline] BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076 CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline] current_nat_addr fs/f2fs/node.h:213 [inline] f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline] f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838 __do_sys_ioctl fs/ioctl.c:902 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is we missed to do sanity check on i_xattr_nid during f2fs_iget(), so that in fiemap() path, current_nat_addr() will access nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering kasan bug report, fix it.

Published: 2024-06-25Modified: 2025-09-17
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-39468
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix deadlock in smb2_find_smb_tcon() Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such deadlock.

Published: 2024-06-25Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39469
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors The error handling in nilfs_empty_dir() when a directory folio/page read fails is incorrect, as in the old ext2 implementation, and if the folio/page cannot be read or nilfs_check_folio() fails, it will falsely determine the directory as empty and corrupt the file system. In addition, since nilfs_empty_dir() does not immediately return on a failed folio/page read, but continues to loop, this can cause a long loop with I/O if i_size of the directory's inode is also corrupted, causing the log writer thread to wait and hang, as reported by syzbot. Fix these issues by making nilfs_empty_dir() immediately return a false value (0) if it fails to get a directory folio/page.

Published: 2024-06-25Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-39471
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add error handle to avoid out-of-bounds if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL.

Published: 2024-06-25Modified: 2024-11-21
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-39473
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension If a process module does not have base config extension then the same format applies to all of it's inputs and the process->base_config_ext is NULL, causing NULL dereference when specifically crafted topology and sequences used.

Published: 2024-07-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39474
MEDIUM5.5

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

Published: 2024-07-05Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39475
MEDIUM5.5

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.

Published: 2024-07-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39476
MEDIUM5.5

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.

Published: 2024-07-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39480
HIGH7.8

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.

Published: 2024-07-05Modified: 2024-11-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-39481
MEDIUM5.5

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.

Published: 2024-07-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39482
MEDIUM5.5

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.

Published: 2024-07-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39483
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a *really* good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support.

Published: 2024-07-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39484
MEDIUM5.5

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)

Published: 2024-07-05Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39485
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Properly re-initialise notifier entry in unregister The notifier_entry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use list_del_init() to return the notifier_entry an empty list.

Published: 2024-07-05Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39487
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it.

Published: 2024-07-09Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-39488
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc ---truncated---

Published: 2024-07-10Modified: 2025-09-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39489
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix memleak in seg6_hmac_init_algo seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly.

Published: 2024-07-10Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39490
MEDIUM6.2

In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix missing sk_buff release in seg6_input_core The seg6_input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6_input_core(). This function uses the skb_cow_head() to ensure that there is sufficient headroom in the sk_buff for accommodating the link-layer header. In the event that the skb_cow_header() function fails, the seg6_input_core() catches the error but it does not release the sk_buff, which will result in a memory leak. This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks. The proposed patch addresses the identified memory leak by requiring the seg6_input_core() function to release the sk_buff in the event that skb_cow_head() fails.

Published: 2024-07-10Modified: 2025-03-24
CVSS 3.xMEDIUM 6.2
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-39494
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.

Published: 2024-07-12Modified: 2026-01-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-39495
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: greybus: Fix use-after-free bug in gb_interface_release due to race condition. In gb_interface_create, &intf->mode_switch_completion is bound with gb_interface_mode_switch_work. Then it will be started by gb_interface_request_mode_switch. Here is the relevant code. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } If we call gb_interface_release to make cleanup, there may be an unfinished work. This function will call kfree to free the object "intf". However, if gb_interface_mode_switch_work is scheduled to run after kfree, it may cause use-after-free error as gb_interface_mode_switch_work will use the object "intf". The possible execution flow that may lead to the issue is as follows: CPU0 CPU1 | gb_interface_create | gb_interface_request_mode_switch gb_interface_release | kfree(intf) (free) | | gb_interface_mode_switch_work | mutex_lock(&intf->mutex) (use) Fix it by canceling the work before kfree.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-39496
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section.

Published: 2024-07-12Modified: 2026-01-06
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-39497
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE) Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Return -EINVAL early if COW mapping is detected. This bug affects all drm drivers using default shmem helpers. It can be reproduced by this simple example: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0;

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39499
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: vmci: prevent speculation leaks by sanitizing event in event_deliver() Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization. This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Only compile tested, no access to HW.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-39500
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: sock_map: avoid race between sock_map_close and sk_psock_put sk_psock_get will return NULL if the refcount of psock has gone to 0, which will happen when the last call of sk_psock_put is done. However, sk_psock_drop may not have finished yet, so the close callback will still point to sock_map_close despite psock being NULL. This can be reproduced with a thread deleting an element from the sock map, while the second one creates a socket, adds it to the map and closes it. That will trigger the WARN_ON_ONCE: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Modules linked in: CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840 R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Call Trace: unix_release+0x87/0xc0 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c:1556 [inline] __se_sys_close fs/open.c:1541 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Use sk_psock, which will only check that the pointer is not been set to NULL yet, which should only happen after the callbacks are restored. If, then, a reference can still be gotten, we may call sk_psock_stop and cancel psock->work. As suggested by Paolo Abeni, reorder the condition so the control flow is less convoluted. After that change, the reproducer does not trigger the WARN_ON_ONCE anymore.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39502
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ionic: fix use after netif_napi_del() When queues are started, netif_napi_add() and napi_enable() are called. If there are 4 queues and only 3 queues are used for the current configuration, only 3 queues' napi should be registered and enabled. The ionic_qcq_enable() checks whether the .poll pointer is not NULL for enabling only the using queue' napi. Unused queues' napi will not be registered by netif_napi_add(), so the .poll pointer indicates NULL. But it couldn't distinguish whether the napi was unregistered or not because netif_napi_del() doesn't reset the .poll pointer to NULL. So, ionic_qcq_enable() calls napi_enable() for the queue, which was unregistered by netif_napi_del(). Reproducer: ethtool -L rx 1 tx 1 combined 0 ethtool -L rx 0 tx 0 combined 1 ethtool -L rx 0 tx 0 combined 4 Splat looks like: kernel BUG at net/core/dev.c:6666! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16 Workqueue: events ionic_lif_deferred_work [ionic] RIP: 0010:napi_enable+0x3b/0x40 Code: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: ? die+0x33/0x90 ? do_trap+0xd9/0x100 ? napi_enable+0x3b/0x40 ? do_error_trap+0x83/0xb0 ? napi_enable+0x3b/0x40 ? napi_enable+0x3b/0x40 ? exc_invalid_op+0x4e/0x70 ? napi_enable+0x3b/0x40 ? asm_exc_invalid_op+0x16/0x20 ? napi_enable+0x3b/0x40 ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] process_one_work+0x145/0x360 worker_thread+0x2bb/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-39505
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/komeda: check for error-valued pointer komeda_pipeline_get_state() may return an error-valued pointer, thus check the pointer for negative or null value before dereferencing.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39506
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39507
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash problem in concurrent scenario When link status change, the nic driver need to notify the roce driver to handle this event, but at this time, the roce driver may uninit, then cause kernel crash. To fix the problem, when link status change, need to check whether the roce registered, and when uninit, need to wait link update finish.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39508
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: Use set_bit() and test_bit() at worker->flags Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq to address potential data races. The structure io_worker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in io_worker_handle_work and io_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198) Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm"). These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as set_bit(), test_bit(), and clear_bit() instead of basic "and" and "or" operations. This ensures thread-safe manipulation of worker flags. Also, move `create_index` to avoid holes in the structure.

Published: 2024-07-12Modified: 2025-10-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-39509
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: HID: core: remove unnecessary WARN_ON() in implement() Syzkaller hit a warning [1] in a call to implement() when trying to write a value into a field of smaller size in an output report. Since implement() already has a warn message printed out with the help of hid_warn() and value in question gets trimmed with: ... value &= m; ... WARN_ON may be considered superfluous. Remove it to suppress future syzkaller triggers. [1] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline] WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 Modules linked in: CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline] RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863 ... Call Trace: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40900
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: cachefiles: remove requests from xarray during flushing requests Even with CACHEFILES_DEAD set, we can still read the requests, so in the following concurrency the request may be used after it has been freed: mount | daemon_thread1 | daemon_thread2 ------------------------------------------------------------ cachefiles_ondemand_init_object cachefiles_ondemand_send_req REQ_A = kzalloc(sizeof(*req) + data_len) wait_for_completion(&REQ_A->done) cachefiles_daemon_read cachefiles_ondemand_daemon_read // close dev fd cachefiles_flush_reqs complete(&REQ_A->done) kfree(REQ_A) xa_lock(&cache->reqs); cachefiles_ondemand_select_req req->msg.opcode != CACHEFILES_OP_READ // req use-after-free !!! xa_unlock(&cache->reqs); xa_destroy(&cache->reqs) Hence remove requests from cache->reqs when flushing them to avoid accessing freed requests.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40901
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory There is a potential out-of-bounds access when using test_bit() on a single word. The test_bit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump: BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965 For full log, please look at [1]. Make the allocation at least the size of sizeof(unsigned long) so that set_bit() and test_bit() have sufficient room for read/write operations without overwriting unallocated memory. [1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40902
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40903
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps There could be a potential use-after-free case in tcpm_register_source_caps(). This could happen when: * new (say invalid) source caps are advertised * the existing source caps are unregistered * tcpm_register_source_caps() returns with an error as usb_power_delivery_register_capabilities() fails This causes port->partner_source_caps to hold on to the now freed source caps. Reset port->partner_source_caps value to NULL after unregistering existing source caps.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40904
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages The syzbot fuzzer found that the interrupt-URB completion callback in the cdc-wdm driver was taking too long, and the driver's immediate resubmission of interrupt URBs with -EPROTO status combined with the dummy-hcd emulation to cause a CPU lockup: cdc_wdm 1-1:1.0: nonzero urb status received: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625] CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idle Modules linked in: irq event stamp: 73096 hardirqs last enabled at (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs last enabled at (73095): [] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs last disabled at (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (73048): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs last disabled at (73043): [] __do_softirq+0x14/0x20 kernel/softirq.c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Testing showed that the problem did not occur if the two error messages -- the first two lines above -- were removed; apparently adding material to the kernel log takes a surprisingly large amount of time. In any case, the best approach for preventing these lockups and to avoid spamming the log with thousands of error messages per second is to ratelimit the two dev_err() calls. Therefore we replace them with dev_err_ratelimited().

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40905
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible race in __fib6_drop_pcpu_from() syzbot found a race in __fib6_drop_pcpu_from() [1] If compiler reads more than once (*ppcpu_rt), second read could read NULL, if another cpu clears the value in rt6_get_pcpu_route(). Add a READ_ONCE() to prevent this race. Also add rcu_read_lock()/rcu_read_unlock() because we rely on RCU protection while dereferencing pcpu_rt. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40906
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always stop health timer during driver removal Currently, if teardown_hca fails to execute during driver removal, mlx5 does not stop the health timer. Afterwards, mlx5 continue with driver teardown. This may lead to a UAF bug, which results in page fault Oops[1], since the health timer invokes after resources were freed. Hence, stop the health monitor even if teardown_hca fails. [1] mlx5_core 0000:18:00.0: E-Switch: Unload vfs: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0) mlx5_core 0000:18:00.0: E-Switch: cleanup mlx5_core 0000:18:00.0: wait_func:1155:(pid 1967079): TEARDOWN_HCA(0x103) timeout. Will cause a leak of a command resource mlx5_core 0000:18:00.0: mlx5_function_close:1288:(pid 1967079): tear_down_hca failed, skip cleanup BUG: unable to handle page fault for address: ffffa26487064230 PGD 100c00067 P4D 100c00067 PUD 100e5a067 PMD 105ed7067 PTE 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE ------- --- 6.7.0-68.fc38.x86_64 #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 RIP: 0010:ioread32be+0x34/0x60 RSP: 0018:ffffa26480003e58 EFLAGS: 00010292 RAX: ffffa26487064200 RBX: ffff9042d08161a0 RCX: ffff904c108222c0 RDX: 000000010bbf1b80 RSI: ffffffffc055ddb0 RDI: ffffa26487064230 RBP: ffff9042d08161a0 R08: 0000000000000022 R09: ffff904c108222e8 R10: 0000000000000004 R11: 0000000000000441 R12: ffffffffc055ddb0 R13: ffffa26487064200 R14: ffffa26480003f00 R15: ffff904c108222c0 FS: 0000000000000000(0000) GS:ffff904c10800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa26487064230 CR3: 00000002c4420006 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x175/0x180 ? asm_exc_page_fault+0x26/0x30 ? __pfx_poll_health+0x10/0x10 [mlx5_core] ? __pfx_poll_health+0x10/0x10 [mlx5_core] ? ioread32be+0x34/0x60 mlx5_health_check_fatal_sensors+0x20/0x100 [mlx5_core] ? __pfx_poll_health+0x10/0x10 [mlx5_core] poll_health+0x42/0x230 [mlx5_core] ? __next_timer_interrupt+0xbc/0x110 ? __pfx_poll_health+0x10/0x10 [mlx5_core] call_timer_fn+0x21/0x130 ? __pfx_poll_health+0x10/0x10 [mlx5_core] __run_timers+0x222/0x2c0 run_timer_softirq+0x1d/0x40 __do_softirq+0xc9/0x2c8 __irq_exit_rcu+0xa6/0xc0 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:cpuidle_enter_state+0xcc/0x440 ? cpuidle_enter_state+0xbd/0x440 cpuidle_enter+0x2d/0x40 do_idle+0x20d/0x270 cpu_startup_entry+0x2a/0x30 rest_init+0xd0/0xd0 arch_call_rest_init+0xe/0x30 start_kernel+0x709/0xa90 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x96/0xa0 secondary_startup_64_no_verify+0x18f/0x19b ---[ end trace 0000000000000000 ]---

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40908
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Set run context for rawtp test_run callback syzbot reported crash when rawtp program executed through the test_run interface calls bpf_get_attach_cookie helper or any other helper that touches task->bpf_ctx pointer. Setting the run context (task->bpf_ctx pointer) for test_run callback.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40910
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ax25: Fix refcount imbalance on inbound connections When releasing a socket in ax25_release(), we call netdev_put() to decrease the refcount on the associated ax.25 device. However, the execution path for accepting an incoming connection never calls netdev_hold(). This imbalance leads to refcount errors, and ultimately to kernel crashes. A typical call trace for the above situation will start with one of the following errors: refcount_t: decrement hit 0; leaking memory. refcount_t: underflow; use-after-free. And will then have a trace like: Call Trace: ? show_regs+0x64/0x70 ? __warn+0x83/0x120 ? refcount_warn_saturate+0xb2/0x100 ? report_bug+0x158/0x190 ? prb_read_valid+0x20/0x30 ? handle_bug+0x3e/0x70 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? refcount_warn_saturate+0xb2/0x100 ? refcount_warn_saturate+0xb2/0x100 ax25_release+0x2ad/0x360 __sock_release+0x35/0xa0 sock_close+0x19/0x20 [...] On reboot (or any attempt to remove the interface), the kernel gets stuck in an infinite loop: unregister_netdevice: waiting for ax0 to become free. Usage count = 0 This patch corrects these issues by ensuring that we call netdev_hold() and ax25_dev_hold() for new connections in ax25_accept(). This makes the logic leading to ax25_accept() match the logic for ax25_bind(): in both cases we increment the refcount, which is ultimately decremented in ax25_release().

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40911
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Lock wiphy in cfg80211_get_station Wiphy should be locked before calling rdev_get_station() (see lockdep assert in ieee80211_get_station()). This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814) This happens because STA has time to disconnect and reconnect before batadv_v_elp_throughput_metric_update() delayed work gets scheduled. In this situation, ath10k_sta_state() can be in the middle of resetting arsta data when the work queue get chance to be scheduled and ends up accessing it. Locking wiphy prevents that.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40912
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup() The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from softirq context. However using only spin_lock() to get sta->ps_lock in ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c __local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 ____sys_sendmsg+0x1e8/0x218 ___sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150 Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise on the same CPU that is holding the lock.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40913
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: cachefiles: defer exposing anon_fd until after copy_to_user() succeeds After installing the anonymous fd, we can now see it in userland and close it. However, at this point we may not have gotten the reference count of the cache, but we will put it during colse fd, so this may cause a cache UAF. So grab the cache reference count before fd_install(). In addition, by kernel convention, fd is taken over by the user land after fd_install(), and the kernel should not call close_fd() after that, i.e., it should call fd_install() after everything is ready, thus fd_install() is called after copy_to_user() succeeds.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40914
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: don't unpoison huge_zero_folio When I did memory failure tests recently, below panic occurs: kernel BUG at include/linux/mm.h:1135! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 137 Comm: kswapd1 Not tainted 6.9.0-rc4-00491-gd5ce28f156fe-dirty #14 RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0 Call Trace: do_shrink_slab+0x14f/0x6a0 shrink_slab+0xca/0x8c0 shrink_node+0x2d0/0x7d0 balance_pgdat+0x33a/0x720 kswapd+0x1f3/0x410 kthread+0xd5/0x100 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 Modules linked in: mce_inject hwpoison_inject ---[ end trace 0000000000000000 ]--- RIP: 0010:shrink_huge_zero_page_scan+0x168/0x1a0 RSP: 0018:ffff9933c6c57bd0 EFLAGS: 00000246 RAX: 000000000000003e RBX: 0000000000000000 RCX: ffff88f61fc5c9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff88f61fc5c9c0 RBP: ffffcd7c446b0000 R08: ffffffff9a9405f0 R09: 0000000000005492 R10: 00000000000030ea R11: ffffffff9a9405f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88e703c4ac00 FS: 0000000000000000(0000) GS:ffff88f61fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f4da6e9878 CR3: 0000000c71048000 CR4: 00000000000006f0 The root cause is that HWPoison flag will be set for huge_zero_folio without increasing the folio refcnt. But then unpoison_memory() will decrease the folio refcnt unexpectedly as it appears like a successfully hwpoisoned folio leading to VM_BUG_ON_PAGE(page_ref_count(page) == 0) when releasing huge_zero_folio. Skip unpoisoning huge_zero_folio in unpoison_memory() to fix this issue. We're not prepared to unpoison huge_zero_folio yet.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40915
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context __kernel_map_pages() is a debug function which clears the valid bit in page table entry for deallocated pages to detect illegal memory accesses to freed pages. This function set/clear the valid bit using __set_memory(). __set_memory() acquires init_mm's semaphore, and this operation may sleep. This is problematic, because __kernel_map_pages() can be called in atomic context, and thus is illegal to sleep. An example warning that this causes: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd preempt_count: 2, expected: 0 CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37 Hardware name: riscv-virtio,qemu (DT) Call Trace: [] dump_backtrace+0x1c/0x24 [] show_stack+0x2c/0x38 [] dump_stack_lvl+0x5a/0x72 [] dump_stack+0x14/0x1c [] __might_resched+0x104/0x10e [] __might_sleep+0x3e/0x62 [] down_write+0x20/0x72 [] __set_memory+0x82/0x2fa [] __kernel_map_pages+0x5a/0xd4 [] __alloc_pages_bulk+0x3b2/0x43a [] __vmalloc_node_range+0x196/0x6ba [] copy_process+0x72c/0x17ec [] kernel_clone+0x60/0x2fe [] kernel_thread+0x82/0xa0 [] kthreadd+0x14a/0x1be [] ret_from_fork+0xe/0x1c Rewrite this function with apply_to_existing_page_range(). It is fine to not have any locking, because __kernel_map_pages() works with pages being allocated/deallocated and those pages are not changed by anyone else in the meantime.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40918
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: parisc: Try to fix random segmentation faults in package builds PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. Another issue is that the present bit in PTEs is racy. 1) PA-RISC caches have a mind of their own and they can speculatively load data and instructions for a page as long as there is a entry in the TLB for the page which allows move-in. TLBs are local to each CPU. Thus, the TLB entry for a page must be purged before flushing the page. This is particularly important on SMP systems. In some of the flush routines, the flush routine would be called and then the TLB entry would be purged. This was because the flush routine needed the TLB entry to do the flush. 2) My initial approach to trying the fix the random faults was to try and use flush_cache_page_if_present for all flush operations. This actually made things worse and led to a couple of hardware lockups. It finally dawned on me that some lines weren't being flushed because the pte check code was racy. This resulted in random inequivalent mappings to physical pages. The __flush_cache_page tmpalias flush sets up its own TLB entry and it doesn't need the existing TLB entry. As long as we can find the pte pointer for the vm page, we can get the pfn and physical address of the page. We can also purge the TLB entry for the page before doing the flush. Further, __flush_cache_page uses a special TLB entry that inhibits cache move-in. When switching page mappings, we need to ensure that lines are removed from the cache. It is not sufficient to just flush the lines to memory as they may come back. This made it clear that we needed to implement all the required flush operations using tmpalias routines. This includes flushes for user and kernel pages. After modifying the code to use tmpalias flushes, it became clear that the random segmentation faults were not fully resolved. The frequency of faults was worse on systems with a 64 MB L2 (PA8900) and systems with more CPUs (rp4440). The warning that I added to flush_cache_page_if_present to detect pages that couldn't be flushed triggered frequently on some systems. Helge and I looked at the pages that couldn't be flushed and found that the PTE was either cleared or for a swap page. Ignoring pages that were swapped out seemed okay but pages with cleared PTEs seemed problematic. I looked at routines related to pte_clear and noticed ptep_clear_flush. The default implementation just flushes the TLB entry. However, it was obvious that on parisc we need to flush the cache page as well. If we don't flush the cache page, stale lines will be left in the cache and cause random corruption. Once a PTE is cleared, there is no way to find the physical address associated with the PTE and flush the associated page at a later time. I implemented an updated change with a parisc specific version of ptep_clear_flush. It fixed the random data corruption on Helge's rp4440 and rp3440, as well as on my c8000. At this point, I realized that I could restore the code where we only flush in flush_cache_page_if_present if the page has been accessed. However, for this, we also need to flush the cache when the accessed bit is cleared in ---truncated---

Published: 2024-07-12Modified: 2025-09-17
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-40919
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Adjust logging of firmware messages in case of released token in __hwrm_send() In case of token is released due to token->state == BNXT_HWRM_DEFERRED, released token (set to NULL) is used in log messages. This issue is expected to be prevented by HWRM_ERR_CODE_PF_UNAVAILABLE error code. But this error code is returned by recent firmware. So some firmware may not return it. This may lead to NULL pointer dereference. Adjust this issue by adding token pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40924
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/i915/dpt: Make DPT object unshrinkable In some scenarios, the DPT object gets shrunk but the actual framebuffer did not and thus its still there on the DPT's vm->bound_list. Then it tries to rewrite the PTEs via a stale CPU mapping. This causes panic. [vsyrjala: Add TODO comment] (cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40927
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: xhci: Handle TD clearing for multiple streams case When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N>1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/"should never happen" paths to ensure we at least clear any affected TDs, even if we can't issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens. This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correct assumptions about number of rings per endpoint.") early on in the XHCI driver's life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 ("xhci: split handling halted endpoints into two steps"), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious). Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs."), it was acknowledged again. [Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cached cancelled URBs.") was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.] Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhci_dbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn't really hint at there being a problem at all). It took me *months* of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn't have been left in at all). > Another fix to solve clearing the caches of all stream rings with > cancelled TDs is needed, but not as urgent. 3 years after that statement and 14 years after the original bug was introduced, I think it's finally time to fix it. And maybe next time let's not leave bugs unfixed (that are actually worse than the original bug), and let's actually get people to review kernel commits please. Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use `hdparm` to mark an early sector (e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn't get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the `cat` in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro'd and tested on an Apple M1 Mac Mini (dwc3 host). On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40929
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: check n_ssids before accessing the ssids In some versions of cfg80211, the ssids poinet might be a valid one even though n_ssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking n_ssids first.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-40931
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure snd_una is properly initialized on connect This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized. Address the issue explicitly initializing snd_una together with snd_nxt and write_seq.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40932
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/exynos/vidi: fix memory leak in .get_modes() The duplicated EDID is never freed. Fix it.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40934
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode() Fix a memory leak on logi_dj_recv_send_report() error path.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40935
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: cachefiles: flush all requests after setting CACHEFILES_DEAD In ondemand mode, when the daemon is processing an open request, if the kernel flags the cache as CACHEFILES_DEAD, the cachefiles_daemon_write() will always return -EIO, so the daemon can't pass the copen to the kernel. Then the kernel process that is waiting for the copen triggers a hung_task. Since the DEAD state is irreversible, it can only be exited by closing /dev/cachefiles. Therefore, after calling cachefiles_io_error() to mark the cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to avoid the above hungtask. We may still be able to read some of the cached data before closing the fd of /dev/cachefiles. Note that this relies on the patch that adds reference counting to the req, otherwise it may UAF.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40937
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: gve: Clear napi->skb before dev_kfree_skb_any() gve_rx_free_skb incorrectly leaves napi->skb referencing an skb after it is freed with dev_kfree_skb_any(). This can result in a subsequent call to napi_get_frags returning a dangling pointer. Fix this by clearing napi->skb before the skb is freed.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40938
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: landlock: Fix d_parent walk The WARN_ON_ONCE() in collect_domain_accesses() can be triggered when trying to link a root mount point. This cannot work in practice because this directory is mounted, but the VFS check is done after the call to security_path_link(). Do not use source directory's d_parent when the source directory is the mount point. [mic: Fix commit message]

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40939
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: Fix tainted pointer delete is case of region creation fail In case of region creation fail in ipc_devlink_create_region(), previously created regions delete process starts from tainted pointer which actually holds error code value. Fix this bug by decreasing region index before delete. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40940
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix tainted pointer delete is case of flow rules creation fail In case of flow rule creation fail in mlx5_lag_create_port_sel_table(), instead of previously created rules, the tainted pointer is deleted deveral times. Fix this bug by using correct flow rules pointers. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40941
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't read past the mfuart notifcation In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing. This was reported by KFENCE.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40942
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects The hwmp code use objects of type mesh_preq_queue, added to a list in ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath gets deleted, ex mesh interface is removed, the entries in that list will never get cleaned. Fix this by flushing all corresponding items of the preq_queue in mesh_path_flush_pending(). This should take care of KASAN reports like this: unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40943
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix races between hole punching and AIO+DIO After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block", fstests/generic/300 become from always failed to sometimes failed: ======================================================================== [ 473.293420 ] run fstests generic/300 [ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3 fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072 ========================================================================= In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2_write_begin_nolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list found there is no such extent at the cpos. T1 T2 T3 inode lock ... insert extents ... inode unlock ocfs2_fallocate __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ... unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ... unlock ip_alloc_sem In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40945
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: iommu: Return right value in iommu_sva_bind_device() iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer. In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40947
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ima: Avoid blocking in RCU read-side critical section A panic happens in ima_match_policy: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 42f873067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 5 PID: 1286325 Comm: kubeletmonit.sh Kdump: loaded Tainted: P Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ima_match_policy+0x84/0x450 Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39 7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d f2 b9 f4 00 0f 84 9c 01 00 00 <44> 85 73 10 74 ea 44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f RSP: 0018:ff71570009e07a80 EFLAGS: 00010207 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200 RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739 R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970 R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001 FS: 00007f5195b51740(0000) GS:ff3e278b12d40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ima_get_action+0x22/0x30 process_measurement+0xb0/0x830 ? page_add_file_rmap+0x15/0x170 ? alloc_set_pte+0x269/0x4c0 ? prep_new_page+0x81/0x140 ? simple_xattr_get+0x75/0xa0 ? selinux_file_open+0x9d/0xf0 ima_file_check+0x64/0x90 path_openat+0x571/0x1720 do_filp_open+0x9b/0x110 ? page_counter_try_charge+0x57/0xc0 ? files_cgroup_alloc_fd+0x38/0x60 ? __alloc_fd+0xd4/0x250 ? do_sys_open+0x1bd/0x250 do_sys_open+0x1bd/0x250 do_syscall_64+0x5d/0x1d0 entry_SYSCALL_64_after_hwframe+0x65/0xca Commit c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()") introduced call to ima_lsm_copy_rule within a RCU read-side critical section which contains kmalloc with GFP_KERNEL. This implies a possible sleep and violates limitations of RCU read-side critical sections on non-PREEMPT systems. Sleeping within RCU read-side critical section might cause synchronize_rcu() returning early and break RCU protection, allowing a UAF to happen. The root cause of this issue could be described as follows: | Thread A | Thread B | | |ima_match_policy | | | rcu_read_lock | |ima_lsm_update_rule | | | synchronize_rcu | | | | kmalloc(GFP_KERNEL)| | | sleep | ==> synchronize_rcu returns early | kfree(entry) | | | | entry = entry->next| ==> UAF happens and entry now becomes NULL (or could be anything). | | entry->action | ==> Accessing entry might cause panic. To fix this issue, we are converting all kmalloc that is called within RCU read-side critical section to use GFP_ATOMIC. [PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40948
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/page_table_check: fix crash on ZONE_DEVICE Not all pages may apply to pgtable check. One example is ZONE_DEVICE pages: they map PFNs directly, and they don't allocate page_ext at all even if there's struct page around. One may reference devm_memremap_pages(). When both ZONE_DEVICE and page-table-check enabled, then try to map some dax memories, one can trigger kernel bug constantly now when the kernel was trying to inject some pfn maps on the dax device: kernel BUG at mm/page_table_check.c:55! While it's pretty legal to use set_pxx_at() for ZONE_DEVICE pages for page fault resolutions, skip all the checks if page_ext doesn't even exist in pgtable checker, which applies to ZONE_DEVICE but maybe more.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40953
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the loads and stores are atomic. In the extremely unlikely scenario the compiler tears the stores, it's theoretically possible for KVM to attempt to get a vCPU using an out-of-bounds index, e.g. if the write is split into multiple 8-bit stores, and is paired with a 32-bit load on a VM with 257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff]; As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40954
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: do not leave a dangling sk pointer, when socket creation fails It is possible to trigger a use-after-free by: * attaching an fentry probe to __sock_release() and the probe calling the bpf_get_socket_cookie() helper * running traceroute -I 1.1.1.1 on a freshly booted VM A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299 CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) kasan_report (mm/kasan/report.c:603) ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189) __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) bpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e bpf_trampoline_6442506592+0x47/0xaf __sock_release (net/socket.c:652) __sock_create (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) sk_prot_alloc (net/core/sock.c:2075) sk_alloc (net/core/sock.c:2134) inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 299 on cpu 2 at 78.328502s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) kasan_save_free_info (mm/kasan/generic.c:582) poison_slab_object (mm/kasan/common.c:242) __kasan_slab_free (mm/kasan/common.c:256) kmem_cache_free (mm/slub.c:4437 mm/slub.c:4511) __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208) inet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by clearing the struct socket reference in sk_common_release() to cover all protocol families create functions, which may already attached the reference to the sk object with sock_init_data().

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40956
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list Use list_for_each_entry_safe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxd_desc_complete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40957
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for PREROUTING hook, in PREROUTING hook, we should passing a valid indev, and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer dereference, as below: [74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090 [74830.655633] #PF: supervisor read access in kernel mode [74830.657888] #PF: error_code(0x0000) - not-present page [74830.659500] PGD 0 P4D 0 [74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI ... [74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter] ... [74830.689725] Call Trace: [74830.690402] [74830.690953] ? show_trace_log_lvl+0x1c4/0x2df [74830.692020] ? show_trace_log_lvl+0x1c4/0x2df [74830.693095] ? ipt_do_table+0x286/0x710 [ip_tables] [74830.694275] ? __die_body.cold+0x8/0xd [74830.695205] ? page_fault_oops+0xac/0x140 [74830.696244] ? exc_page_fault+0x62/0x150 [74830.697225] ? asm_exc_page_fault+0x22/0x30 [74830.698344] ? rpfilter_mt+0x44/0x15e [ipt_rpfilter] [74830.699540] ipt_do_table+0x286/0x710 [ip_tables] [74830.700758] ? ip6_route_input+0x19d/0x240 [74830.701752] nf_hook_slow+0x3f/0xb0 [74830.702678] input_action_end_dx4+0x19b/0x1e0 [74830.703735] ? input_action_end_t+0xe0/0xe0 [74830.704734] seg6_local_input_core+0x2d/0x60 [74830.705782] lwtunnel_input+0x5b/0xb0 [74830.706690] __netif_receive_skb_one_core+0x63/0xa0 [74830.707825] process_backlog+0x99/0x140 [74830.709538] __napi_poll+0x2c/0x160 [74830.710673] net_rx_action+0x296/0x350 [74830.711860] __do_softirq+0xcb/0x2ac [74830.713049] do_softirq+0x63/0x90 input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally trigger a NULL dereference in rpfilter_mt()->rpfilter_is_loopback(): static bool rpfilter_is_loopback(const struct sk_buff *skb, const struct net_device *in) { // in is NULL return skb->pkt_type == PACKET_LOOPBACK || in->flags & IFF_LOOPBACK; }

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40958
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: netns: Make get_net_ns() handle zero refcount net Syzkaller hit a warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0 Modules linked in: CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0xdf/0x1d0 Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1 RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001 RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139 R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4 R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040 FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0xa3/0xc0 ? __warn+0xa5/0x1c0 ? refcount_warn_saturate+0xdf/0x1d0 ? report_bug+0x1fc/0x2d0 ? refcount_warn_saturate+0xdf/0x1d0 ? handle_bug+0xa1/0x110 ? exc_invalid_op+0x3c/0xb0 ? asm_exc_invalid_op+0x1f/0x30 ? __warn_printk+0xcc/0x140 ? __warn_printk+0xd5/0x140 ? refcount_warn_saturate+0xdf/0x1d0 get_net_ns+0xa4/0xc0 ? __pfx_get_net_ns+0x10/0x10 open_related_ns+0x5a/0x130 __tun_chr_ioctl+0x1616/0x2370 ? __sanitizer_cov_trace_switch+0x58/0xa0 ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30 ? __pfx_tun_chr_ioctl+0x10/0x10 tun_chr_ioctl+0x2f/0x40 __x64_sys_ioctl+0x11b/0x160 x64_sys_call+0x1211/0x20d0 do_syscall_64+0x9e/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5b28f165d7 Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8 RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7 RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003 RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0 R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730 R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 Kernel panic - not syncing: kernel: panic_on_warn set ... This is trigger as below: ns0 ns1 tun_set_iff() //dev is tun0 tun->dev = dev //ip link set tun0 netns ns1 put_net() //ref is 0 __tun_chr_ioctl() //TUNGETDEVNETNS net = dev_net(tun->dev); open_related_ns(&net->ns, get_net_ns); //ns1 get_net_ns() get_net() //addition on 0 Use maybe_get_net() in get_net_ns in case net's ref is zero to fix this

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40959
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr() ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835 xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40960
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible NULL dereference in rt6_probe() syzbot caught a NULL dereference in rt6_probe() [1] Bail out if __in6_dev_get() returns NULL. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline] RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758 Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: 0018:ffffc900034af070 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000 FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784 nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825 find_rr_leaf net/ipv6/route.c:853 [inline] rt6_select net/ipv6/route.c:897 [inline] fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231 pol_lookup_func include/net/ip6_fib.h:616 [inline] fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline] ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651 ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147 ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250 rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898 inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x4b8/0x5c0 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x6b6/0x1140 fs/read_write.c:590 ksys_write+0x1f8/0x260 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40961
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible NULL deref in fib6_nh_init() syzbot reminds us that in6_dev_get() can return NULL. fib6_nh_init() ip6_validate_gw( &idev ) ip6_route_check_nh( idev ) *idev = in6_dev_get(dev); // can be NULL Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606 Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b RSP: 0018:ffffc900032775a0 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8 RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000 R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8 R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000 FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809 ip6_route_add+0x28/0x160 net/ipv6/route.c:3853 ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483 inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f940f07cea9

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40963
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mips: bmips: BCM6358: make sure CBR is correctly set It was discovered that some device have CBR address set to 0 causing kernel panic when arch_sync_dma_for_cpu_all is called. This was notice in situation where the system is booted from TP1 and BMIPS_GET_CBR() returns 0 instead of a valid address and !!(read_c0_brcm_cmt_local() & (1 << 31)); not failing. The current check whether RAC flush should be disabled or not are not enough hence lets check if CBR is a valid address or not.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40966
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tty: add the option to have a tty reject a new ldisc ... and use it to limit the virtual terminals to just N_TTY. They are kind of special, and in particular, the "con_write()" routine violates the "writes cannot sleep" rule that some ldiscs rely on. This avoids the BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659 when N_GSM has been attached to a virtual console, and gsmld_write() calls con_write() while holding a spinlock, and con_write() then tries to get the console lock.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40967
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: serial: imx: Introduce timeout when waiting on transmitter empty By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40968
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: MIPS: Octeon: Add PCIe link status check The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40969
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: don't set RO when shutting down f2fs Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below. f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread - bdev_freeze - freeze_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - set RO - waiting - bdev_thaw - thaw_super_locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread);

Published: 2024-07-12Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40970
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Avoid hw_desc array overrun in dw-axi-dmac I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3 segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put() handles the hw_desc considering the descs_allocated, this scenario would result in a kernel panic (hw_desc array will be overrun). To fix this, the proposal is to add a new member to the axi_dma_desc structure, where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in axi_desc_put() to handle the hw_desc array correctly. Additionally I propose to remove the axi_chan_start_first_queued() call after completing the transfer, since it was identified that unbalance can occur (started descriptors can be interrupted and transfer ignored due to DMA channel not being enabled).

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40971
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: remove clear SB_INLINECRYPT flag in default_options In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40972
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: do not create EA inode under buffer lock ext4_xattr_set_entry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40973
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: mtk-vcodec: potential null pointer deference in SCP The return value of devm_kzalloc() needs to be checked to avoid NULL pointer deference. This is similar to CVE-2022-3113.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40974
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40976
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/lima: mask irqs in timeout path before hard reset There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40977
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921s: fix potential hung tasks during chip recovery During chip recovery (e.g. chip reset), there is a possible situation that kernel worker reset_work is holding the lock and waiting for kernel thread stat_worker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device. This patch prevents the execution of stat_worker during the chip recovery.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40978
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix crash while reading debugfs attribute The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly on a __user pointer, which results into the crash. To fix this issue, use a small local stack buffer for sprintf() and then call simple_read_from_buffer(), which in turns make the copy_to_user() call. BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-40980
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drop_monitor: replace spin_lock by raw_spin_lock trace_drop_common() is called with preemption disabled, and it acquires a spin_lock. This is problematic for RT kernels because spin_locks are sleeping locks in this configuration, which causes the following splat: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47 preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 2 5 locks held by rcuc/47/449: #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290 irq event stamp: 139909 hardirqs last enabled at (139908): [] _raw_spin_unlock_irqrestore+0x63/0x80 hardirqs last disabled at (139909): [] trace_drop_common.constprop.0+0x26d/0x290 softirqs last enabled at (139892): [] __local_bh_enable_ip+0x103/0x170 softirqs last disabled at (139898): [] rcu_cpu_kthread+0x93/0x1f0 Preemption disabled at: [] rt_mutex_slowunlock+0xab/0x2e0 CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7 Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022 Call Trace: dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0 ? _raw_spin_unlock_irqrestore+0x4a/0x80 ? __pfx_trace_drop_common.constprop.0+0x10/0x10 ? rt_mutex_slowunlock+0x26a/0x2e0 ? skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_rt_mutex_slowunlock+0x10/0x10 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520 ... trace_drop_common() also disables interrupts, but this is a minor issue because we could easily replace it with a local_lock. Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic context.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40981
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: batman-adv: bypass empty buckets in batadv_purge_orig_ref() Many syzbot reports are pointing to soft lockups in batadv_purge_orig_ref() [1] Root cause is unknown, but we can avoid spending too much time there and perhaps get more interesting reports. [1] watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621] Modules linked in: irq event stamp: 6182794 hardirqs last enabled at (6182793): [] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 hardirqs last disabled at (6182794): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (6182794): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (6182792): [] spin_unlock_bh include/linux/spinlock.h:396 [inline] softirqs last enabled at (6182792): [] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 softirqs last disabled at (6182790): [] spin_lock_bh include/linux/spinlock.h:356 [inline] softirqs last disabled at (6182790): [] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271 CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_purge_orig pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline] pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388 lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 sp : ffff800099007970 x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000 x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001 x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4 x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0 x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001 x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000 Call trace: __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline] arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline] __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51 lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103 sp : ffff800093a17d30 x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4 x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002 x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000 x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396 x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001 ---truncated---

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40983
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tipc: force a dst refcount before doing decryption As it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount before entering the xfrm type handlers"): "Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers." On TIPC decryption path it has the same problem, and skb_dst_force() should be called before doing decryption to avoid a possible crash. Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40984
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine." Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference. Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40987
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix UBSAN warning in kv_dpm.c Adds bounds check for sumo_vid_mapping_entry.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40988
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix UBSAN warning in kv_dpm.c Adds bounds check for sumo_vid_mapping_entry.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40989
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Disassociate vcpus from redistributor region on teardown When tearing down a redistributor region, make sure we don't have any dangling pointer to that region stored in a vcpu.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40990
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Add check for srq max_sge attribute max_sge attribute is passed by the user, and is inserted and used unchecked, so verify that the value doesn't exceed maximum allowed value before using it.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40994
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ptp: fix integer overflow in max_vclocks_store On 32bit systems, the "4 * max" multiply can overflow. Use kcalloc() to do the allocation to prevent this.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-40995
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() syzbot found hanging tasks waiting on rtnl_lock [1] A reproducer is available in the syzbot bug. When a request to add multiple actions with the same index is sent, the second request will block forever on the first request. This holds rtnl_lock, and causes tasks to hang. Return -EAGAIN to prevent infinite looping, while keeping documented behavior. [1] INFO: task kworker/1:0:5088 blocked for more than 143 seconds. Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000 Workqueue: events_power_efficient reg_check_chans_work Call Trace: context_switch kernel/sched/core.c:5409 [inline] __schedule+0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 [inline] schedule+0xe7/0x350 kernel/sched/core.c:6838 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [inline] reg_leave_invalid_chans net/wireless/reg.c:2466 [inline] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40997
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: fix memory leak on CPU EPP exit The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is not freed in the analogous exit function, so fix that. [ rjw: Subject and changelog edits ]

Published: 2024-07-12Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-40998
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super() In the following concurrency we will access the uninitialized rs->lock: ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock __raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, _RET_IP_) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock here and get the following dump_stack: ========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4] [...] ========================================================= Normally interval is 0 until s_msg_ratelimit_state is initialized, so ___ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.

Published: 2024-07-12Modified: 2025-09-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41000
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: block/ioctl: prefer different overflow check Running syzkaller with the newly reintroduced signed integer overflow sanitizer shows this report: [ 62.982337] ------------[ cut here ]------------ [ 62.985692] cgroup: Invalid name [ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46 [ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1 [ 62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long' [ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1 [ 62.999369] random: crng reseeded on system resumption [ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000) [ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 63.000682] Call Trace: [ 63.000686] [ 63.000731] dump_stack_lvl+0x93/0xd0 [ 63.000919] __get_user_pages+0x903/0xd30 [ 63.001030] __gup_longterm_locked+0x153e/0x1ba0 [ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50 [ 63.001072] ? try_get_folio+0x29c/0x2d0 [ 63.001083] internal_get_user_pages_fast+0x1119/0x1530 [ 63.001109] iov_iter_extract_pages+0x23b/0x580 [ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220 [ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410 [ 63.001297] __iomap_dio_rw+0xab4/0x1810 [ 63.001316] iomap_dio_rw+0x45/0xa0 [ 63.001328] ext4_file_write_iter+0xdde/0x1390 [ 63.001372] vfs_write+0x599/0xbd0 [ 63.001394] ksys_write+0xc8/0x190 [ 63.001403] do_syscall_64+0xd4/0x1b0 [ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60 [ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77 [ 63.001535] RIP: 0033:0x7f7fd3ebf539 [ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 [ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539 [ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004 [ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000 [ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8 ... [ 63.018142] ---[ end trace ]--- Historically, the signed integer overflow sanitizer did not work in the kernel due to its interaction with `-fwrapv` but this has since been changed [1] in the newest version of Clang; It was re-enabled in the kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow sanitizer"). Let's rework this overflow checking logic to not actually perform an overflow during the check itself, thus avoiding the UBSAN splat. [1]: https://github.com/llvm/llvm-project/pull/82432

Published: 2024-07-12Modified: 2026-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41001
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: work around a potential audit memory leak kmemleak complains that there's a memory leak related to connect handling: unreferenced object 0xffff0001093bdf00 (size 128): comm "iou-sqp-455", pid 457, jiffies 4294894164 hex dump (first 32 bytes): 02 00 fa ea 7f 00 00 01 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 (crc 2e481b1a): [<00000000c0a26af4>] kmemleak_alloc+0x30/0x38 [<000000009c30bb45>] kmalloc_trace+0x228/0x358 [<000000009da9d39f>] __audit_sockaddr+0xd0/0x138 [<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8 [<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4 [<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48 [<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4 [<00000000d999b491>] ret_from_fork+0x10/0x20 which can can happen if: 1) The command type does something on the prep side that triggers an audit call. 2) The thread hasn't done any operations before this that triggered an audit call inside ->issue(), where we have audit_uring_entry() and audit_uring_exit(). Work around this by issuing a blanket NOP operation before the SQPOLL does anything.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41002
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - Fix memory leak for sec resource release The AIV is one of the SEC resources. When releasing resources, it need to release the AIV resources at the same time. Otherwise, memory leakage occurs. The aiv resource release is added to the sec resource release function.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41004
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tracing: Build event generation tests only as modules The kprobes and synth event generation test modules add events and lock (get a reference) those event file reference in module init function, and unlock and delete it in module exit function. This is because those are designed for playing as modules. If we make those modules as built-in, those events are left locked in the kernel, and never be removed. This causes kprobe event self-test failure as below. [ 97.349708] ------------[ cut here ]------------ [ 97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480 [ 97.357106] Modules linked in: [ 97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14 [ 97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480 [ 97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 <0f> 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90 [ 97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286 [ 97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000 [ 97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68 [ 97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000 [ 97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000 [ 97.381536] FS: 0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000 [ 97.383813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0 [ 97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 97.391196] Call Trace: [ 97.391967] [ 97.392647] ? __warn+0xcc/0x180 [ 97.393640] ? kprobe_trace_self_tests_init+0x3f1/0x480 [ 97.395181] ? report_bug+0xbd/0x150 [ 97.396234] ? handle_bug+0x3e/0x60 [ 97.397311] ? exc_invalid_op+0x1a/0x50 [ 97.398434] ? asm_exc_invalid_op+0x1a/0x20 [ 97.399652] ? trace_kprobe_is_busy+0x20/0x20 [ 97.400904] ? tracing_reset_all_online_cpus+0x15/0x90 [ 97.402304] ? kprobe_trace_self_tests_init+0x3f1/0x480 [ 97.403773] ? init_kprobe_trace+0x50/0x50 [ 97.404972] do_one_initcall+0x112/0x240 [ 97.406113] do_initcall_level+0x95/0xb0 [ 97.407286] ? kernel_init+0x1a/0x1a0 [ 97.408401] do_initcalls+0x3f/0x70 [ 97.409452] kernel_init_freeable+0x16f/0x1e0 [ 97.410662] ? rest_init+0x1f0/0x1f0 [ 97.411738] kernel_init+0x1a/0x1a0 [ 97.412788] ret_from_fork+0x39/0x50 [ 97.413817] ? rest_init+0x1f0/0x1f0 [ 97.414844] ret_from_fork_asm+0x11/0x20 [ 97.416285] [ 97.417134] irq event stamp: 13437323 [ 97.418376] hardirqs last enabled at (13437337): [] console_unlock+0x11c/0x150 [ 97.421285] hardirqs last disabled at (13437370): [] console_unlock+0x101/0x150 [ 97.423838] softirqs last enabled at (13437366): [] handle_softirqs+0x23f/0x2a0 [ 97.426450] softirqs last disabled at (13437393): [] __irq_exit_rcu+0x66/0xd0 [ 97.428850] ---[ end trace 0000000000000000 ]--- And also, since we can not cleanup dynamic_event file, ftracetest are failed too. To avoid these issues, build these tests only as modules.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41005
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: netpoll: Fix race condition in netpoll_owner_active KCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) value changed: 0x0000000a -> 0xffffffff This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock. Use an atomic read to check if the poll owner is the current CPU.

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41006
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netrom: Fix a memory leak in nr_heartbeat_expiry() syzbot reported a memory leak in nr_create() [0]. Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.") added sock_hold() to the nr_heartbeat_expiry() function, where a) a socket has a SOCK_DESTROY flag or b) a listening socket has a SOCK_DEAD flag. But in the case "a," when the SOCK_DESTROY flag is set, the file descriptor has already been closed and the nr_release() function has been called. So it makes no sense to hold the reference count because no one will call another nr_destroy_socket() and put it as in the case "b." nr_connect nr_establish_data_link nr_start_heartbeat nr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY); nr_rx_frame nr_process_rx_frame switch (nr->state) case NR_STATE_2 nr_state2_machine() nr_disconnect() nr_sk(sk)->state = NR_STATE_0 sock_set_flag(sk, SOCK_DEAD) nr_heartbeat_expiry switch (nr->state) case NR_STATE_0 if (sock_flag(sk, SOCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) sock_hold() // ( !!! ) nr_destroy_socket() To fix the memory leak, let's call sock_hold() only for a listening socket. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. [0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16

Published: 2024-07-12Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41007
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: tcp: avoid too many retransmit packets If a TCP socket is using TCP_USER_TIMEOUT, and the other peer retracted its window to zero, tcp_retransmit_timer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCP_USER_TIMEOUT has 'expired'. The fix is to make sure tcp_rtx_probe0_timed_out() takes icsk->icsk_user_timeout into account. Before blamed commit, the socket would not timeout after icsk->icsk_user_timeout, but would use standard exponential backoff for the retransmits. Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4.

Published: 2024-07-15Modified: 2025-11-03
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-41009
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter.

Published: 2024-07-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41011
HIGH7.8

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.

Published: 2024-07-18Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41012
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush().

Published: 2024-07-23Modified: 2025-11-03
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-41015
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ocfs2: add bounds checking to ocfs2_check_dir_entry() This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41016
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry() xattr in ocfs2 maybe 'non-indexed', which saved with additional space requested. It's better to check if the memory is out of bound before memcmp, although this possibility mainly comes from crafted poisonous images.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41017
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: jfs: don't walk off the end of ealist Add a check before visiting the members of ea to make sure each ea stays within the ealist.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41019
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Validate ff offset This adds sanity checks for ff offset. There is a check on rt->first_free at first, but walking through by ff without any check. If the second ff is a large offset. We may encounter an out-of-bound read.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41020
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: filelock: Fix fcntl/close race recovery compat path When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41027
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: Fix userfaultfd_api to return EINVAL as expected Currently if we request a feature that is not set in the Kernel config we fail silently and return all the available features. However, the man page indicates we should return an EINVAL. We need to fix this issue since we can end up with a Kernel warning should a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with the config not set with this feature. [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-41028
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: platform/x86: toshiba_acpi: Fix array out-of-bounds access In order to use toshiba_dmi_quirks[] together with the standard DMI matching functions, it must be terminated by a empty entry. Since this entry is missing, an array out-of-bounds access occurs every time the quirk list is processed. Fix this by adding the terminating empty entry.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41030
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ksmbd: discard write access to the directory open may_open() does not allow a directory to be opened with the write access. However, some writing flags set by client result in adding write access on server, making ksmbd incompatible with FUSE file system. Simply, let's discard the write access when opening a directory. list_add corruption. next is NULL. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:26! pc : __list_add_valid+0x88/0xbc lr : __list_add_valid+0x88/0xbc Call trace: __list_add_valid+0x88/0xbc fuse_finish_open+0x11c/0x170 fuse_open_common+0x284/0x5e8 fuse_dir_open+0x14/0x24 do_dentry_open+0x2a4/0x4e0 dentry_open+0x50/0x80 smb2_open+0xbe4/0x15a4 handle_ksmbd_work+0x478/0x5ec process_one_work+0x1b4/0x448 worker_thread+0x25c/0x430 kthread+0x104/0x1d4 ret_from_fork+0x10/0x20

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41031
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/filemap: skip to create PMD-sized page cache if needed On ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB. The PMD-sized page cache can't be supported by xarray as the following error messages indicate. ------------[ cut here ]------------ WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm \ fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \ sha1_ce virtio_net net_failover virtio_console virtio_blk failover \ dimlib virtio_mmio CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff800087a4f6c0 x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858 x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000 x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28 x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8 x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xas_split_alloc+0xf8/0x128 split_huge_page_to_list_to_order+0x1c4/0x720 truncate_inode_partial_folio+0xdc/0x160 truncate_inode_pages_range+0x1b4/0x4a8 truncate_pagecache_range+0x84/0xa0 xfs_flush_unmap_range+0x70/0x90 [xfs] xfs_file_fallocate+0xfc/0x4d8 [xfs] vfs_fallocate+0x124/0x2e8 ksys_fallocate+0x4c/0xa0 __arm64_sys_fallocate+0x24/0x38 invoke_syscall.constprop.0+0x7c/0xd8 do_el0_svc+0xb4/0xd0 el0_svc+0x44/0x1d8 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Fix it by skipping to allocate PMD-sized page cache when its size is larger than MAX_PAGECACHE_ORDER. For this specific case, we will fall to regular path where the readahead window is determined by BDI's sysfs file (read_ahead_kb).

Published: 2024-07-29Modified: 2025-10-07
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41034
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug on rename operation of broken directory Syzbot reported that in rename directory operation on broken directory on nilfs2, __block_write_begin_int() called to prepare block write may fail BUG_ON check for access exceeding the folio/page size. This is because nilfs_dotdot(), which gets parent directory reference entry ("..") of the directory to be moved or renamed, does not check consistency enough, and may return location exceeding folio/page size for broken directories. Fix this issue by checking required directory entries ("." and "..") in the first chunk of the directory in nilfs_dotdot().

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41035
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpoint_is_duplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk). To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usb_parse_endpoint() and use the copy instead of the original when checking for duplicates.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41036
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: ks8851: Fix deadlock with the SPI chip variant When SMP is enabled and spinlocks are actually functional then there is a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi and ks8851_irq: watchdog: BUG: soft lockup - CPU#0 stuck for 27s! call trace: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c dev_hard_start_xmit+0x6c/0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 ret_from_fork+0x10/0x20 This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs. Now use spin_(un)lock_bh for TX queue related locking to avoid execution of softirq work synchronously that would lead to a deadlock.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41038
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headers Check that all fields of a V2 algorithm header fit into the available firmware data buffer. The wmfw V2 format introduced variable-length strings in the algorithm block header. This means the overall header length is variable, and the position of most fields varies depending on the length of the string fields. Each field must be checked to ensure that it does not overflow the firmware data buffer. As this ia bugfix patch, the fixes avoid making any significant change to the existing code. This makes it easier to review and less likely to introduce new bugs.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41039
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Fix overflow checking of wmfw header Fix the checking that firmware file buffer is large enough for the wmfw header, to prevent overrunning the buffer. The original code tested that the firmware data buffer contained enough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footer But wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 and Halo Core the equivalent struct is wmfw_adsp2_sizes, which is 4 bytes longer. So the length check didn't guarantee that there are enough bytes in the firmware buffer for a header with wmfw_adsp2_sizes. This patch splits the length check into three separate parts. Each of the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checked separately before they are used.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41040
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix UAF when resolving a clash KASAN reports the following UAF: BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] Read of size 1 at addr ffff888c07603600 by task handler130/6469 Call Trace: dump_stack_lvl+0x48/0x70 print_address_description.constprop.0+0x33/0x3d0 print_report+0xc0/0x2b0 kasan_report+0xd0/0x120 __asan_load1+0x6c/0x80 tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] tcf_ct_act+0x886/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 __irq_exit_rcu+0x82/0xc0 irq_exit_rcu+0xe/0x20 common_interrupt+0xa1/0xb0 asm_common_interrupt+0x27/0x40 Allocated by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_alloc_info+0x1e/0x40 __kasan_krealloc+0x133/0x190 krealloc+0xaa/0x130 nf_ct_ext_add+0xed/0x230 [nf_conntrack] tcf_ct_act+0x1095/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 Freed by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_free_info+0x2b/0x60 ____kasan_slab_free+0x180/0x1f0 __kasan_slab_free+0x12/0x30 slab_free_freelist_hook+0xd2/0x1a0 __kmem_cache_free+0x1a2/0x2f0 kfree+0x78/0x120 nf_conntrack_free+0x74/0x130 [nf_conntrack] nf_ct_destroy+0xb2/0x140 [nf_conntrack] __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack] nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack] __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack] tcf_ct_act+0x12ad/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 The ct may be dropped if a clash has been resolved but is still passed to the tcf_ct_flow_table_process_conn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41041
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port(). syzkaller triggered the warning [0] in udp_v4_early_demux(). In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount of the looked-up sk and use sock_pfree() as skb->destructor, so we check SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace period. Currently, SOCK_RCU_FREE is flagged for a bound socket after being put into the hash table. Moreover, the SOCK_RCU_FREE check is done too early in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race window: CPU1 CPU2 ---- ---- udp_v4_early_demux() udp_lib_get_port() | |- hlist_add_head_rcu() |- sk = __udp4_lib_demux_lookup() | |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk)); `- sock_set_flag(sk, SOCK_RCU_FREE) We had the same bug in TCP and fixed it in commit 871019b22d1b ("net: set SOCK_RCU_FREE before inserting socket into hashtable"). Let's apply the same fix for UDP. [0]: WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599 Modules linked in: CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599 Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52 RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001 RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680 R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e FS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349 ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624 __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738 netif_receive_skb_internal net/core/dev.c:5824 [inline] netif_receive_skb+0x271/0x300 net/core/dev.c:5884 tun_rx_batched drivers/net/tun.c:1549 [inline] tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002 tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x76f/0x8d0 fs/read_write.c:590 ksys_write+0xbf/0x190 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x41/0x50 fs/read_write.c:652 x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fc44a68bc1f Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48 RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f R ---truncated---

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41042
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prefer nft_chain_validate nft_chain_validate already performs loop detection because a cycle will result in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE). It also follows maps via ->validate callback in nft_lookup, so there appears no reason to iterate the maps again. nf_tables_check_loops() and all its helper functions can be removed. This improves ruleset load time significantly, from 23s down to 12s. This also fixes a crash bug. Old loop detection code can result in unbounded recursion: BUG: TASK stack guard page was hit at .... Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1 [..] with a suitable ruleset during validation of register stores. I can't see any actual reason to attempt to check for this from nft_validate_register_store(), at this point the transaction is still in progress, so we don't have a full picture of the rule graph. For nf-next it might make sense to either remove it or make this depend on table->validate_state in case we could catch an error earlier (for improved error reporting to userspace).

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41044
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ppp: reject claimed-as-LCP but actually malformed packets Since 'ppp_async_encode()' assumes valid LCP packets (with code from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that LCP packet has an actual body beyond PPP_LCP header bytes, and reject claimed-as-LCP but actually malformed data otherwise.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41046
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix double free in detach The number of the currently released descriptor is never incremented which results in the same skb being released multiple times.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41047
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i40e: Fix XDP program unloading while removing the driver The commit 6533e558c650 ("i40e: Fix reset path while removing the driver") introduced a new PF state "__I40E_IN_REMOVE" to block modifying the XDP program while the driver is being removed. Unfortunately, such a change is useful only if the ".ndo_bpf()" callback was called out of the rmmod context because unloading the existing XDP program is also a part of driver removing procedure. In other words, from the rmmod context the driver is expected to unload the XDP program without reporting any errors. Otherwise, the kernel warning with callstack is printed out to dmesg. Example failing scenario: 1. Load the i40e driver. 2. Load the XDP program. 3. Unload the i40e driver (using "rmmod" command). The example kernel warning log: [ +0.004646] WARNING: CPU: 94 PID: 10395 at net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870 [...] [ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/0x870 [...] [ +0.002726] Call Trace: [ +0.002457] [ +0.002119] ? __warn+0x80/0x120 [ +0.003245] ? unregister_netdevice_many_notify+0x7a9/0x870 [ +0.005586] ? report_bug+0x164/0x190 [ +0.003678] ? handle_bug+0x3c/0x80 [ +0.003503] ? exc_invalid_op+0x17/0x70 [ +0.003846] ? asm_exc_invalid_op+0x1a/0x20 [ +0.004200] ? unregister_netdevice_many_notify+0x7a9/0x870 [ +0.005579] ? unregister_netdevice_many_notify+0x3cc/0x870 [ +0.005586] unregister_netdevice_queue+0xf7/0x140 [ +0.004806] unregister_netdev+0x1c/0x30 [ +0.003933] i40e_vsi_release+0x87/0x2f0 [i40e] [ +0.004604] i40e_remove+0x1a1/0x420 [i40e] [ +0.004220] pci_device_remove+0x3f/0xb0 [ +0.003943] device_release_driver_internal+0x19f/0x200 [ +0.005243] driver_detach+0x48/0x90 [ +0.003586] bus_remove_driver+0x6d/0xf0 [ +0.003939] pci_unregister_driver+0x2e/0xb0 [ +0.004278] i40e_exit_module+0x10/0x5f0 [i40e] [ +0.004570] __do_sys_delete_module.isra.0+0x197/0x310 [ +0.005153] do_syscall_64+0x85/0x170 [ +0.003684] ? syscall_exit_to_user_mode+0x69/0x220 [ +0.004886] ? do_syscall_64+0x95/0x170 [ +0.003851] ? exc_page_fault+0x7e/0x180 [ +0.003932] entry_SYSCALL_64_after_hwframe+0x71/0x79 [ +0.005064] RIP: 0033:0x7f59dc9347cb [ +0.003648] Code: 73 01 c3 48 8b 0d 65 16 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48 [ +0.018753] RSP: 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb [ +0.007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748 [ +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000000 [ +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000 [ +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 R15: 0000000000000000 [ +0.007151] [ +0.002204] ---[ end trace 0000000000000000 ]--- Fix this by checking if the XDP program is being loaded or unloaded. Then, block only loading a new program while "__I40E_IN_REMOVE" is set. Also, move testing "__I40E_IN_REMOVE" flag to the beginning of XDP_SETUP callback to avoid unnecessary operations and checks.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41048
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: skmsg: Skip zero length skb in sk_msg_recvmsg When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch platform, the following kernel panic occurs: [...] Oops[#1]: CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560 ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copy_page_to_iter+0x74/0x1c0 [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560 [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0 [<90000000049aae34>] inet_recvmsg+0x54/0x100 [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0 [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0 [<900000000481e27c>] sys_recvfrom+0x1c/0x40 [<9000000004c076ec>] do_syscall+0x8c/0xc0 [<9000000003731da4>] handle_syscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...] This crash happens every time when running sockmap_skb_verdict_shutdown subtest in sockmap_basic. This crash is because a NULL pointer is passed to page_address() in the sk_msg_recvmsg(). Due to the different implementations depending on the architecture, page_address(NULL) will trigger a panic on Loongarch platform but not on x86 platform. So this bug was hidden on x86 platform for a while, but now it is exposed on Loongarch platform. The root cause is that a zero length skb (skb->len == 0) was put on the queue. This zero length skb is a TCP FIN packet, which was sent by shutdown(), invoked in test_sockmap_skb_verdict_shutdown(): shutdown(p1, SHUT_WR); In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no page is put to this sge (see sg_set_page in sg_set_page), but this empty sge is queued into ingress_msg list. And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it to kmap_local_page() and to page_address(), then kernel panics. To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(), if copy is zero, that means it's a zero length skb, skip invoking copy_page_to_iter(). We are using the EFAULT return triggered by copy_page_to_iter to check for is_fin in tcp_bpf.c.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41049
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: filelock: fix potential use-after-free in posix_lock_inode Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode's list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn't happen.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41050
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: cachefiles: cyclic allocation of msg_id to avoid reuse Reusing the msg_id after a maliciously completed reopen request may cause a read request to remain unprocessed and result in a hung, as shown below: t1 | t2 | t3 ------------------------------------------------- cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // get msg_id 6 wait_for_completion(&req_A->done) cachefiles_ondemand_daemon_read // read msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Malicious completion msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // will not set the object to close // because ondemand_id && fd is valid. // ondemand_object_worker() is done // but the object is still reopening. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reuse msg_id 6 process_open_req copen 6,A.size // The expected failed copen was executed successfully Expect copen to fail, and when it does, it closes fd, which sets the object to close, and then close triggers reopen again. However, due to msg_id reuse resulting in a successful copen, the anonymous fd is not closed until the daemon exits. Therefore read requests waiting for reopen to complete may trigger hung task. To avoid this issue, allocate the msg_id cyclically to avoid reusing the msg_id for a very short duration of time.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41055
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm: prevent derefencing NULL ptr in pfn_section_valid() Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage") changed pfn_section_valid() to add a READ_ONCE() call around "ms->usage" to fix a race with section_deactivate() where ms->usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41056
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw files Use strnlen() instead of strlen() on the algorithm and coefficient name string arrays in V1 wmfw files. In V1 wmfw files the name is a NUL-terminated string in a fixed-size array. cs_dsp should protect against overrunning the array if the NUL terminator is missing.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41057
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in cachefiles_withdraw_cookie() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in cachefiles_withdraw_cookie+0x4d9/0x600 Read of size 8 at addr ffff888118efc000 by task kworker/u78:0/109 CPU: 13 PID: 109 Comm: kworker/u78:0 Not tainted 6.8.0-dirty #566 Call Trace: kasan_report+0x93/0xc0 cachefiles_withdraw_cookie+0x4d9/0x600 fscache_cookie_state_machine+0x5c8/0x1230 fscache_cookie_worker+0x91/0x1c0 process_one_work+0x7fa/0x1800 [...] Allocated by task 117: kmalloc_trace+0x1b3/0x3c0 cachefiles_acquire_volume+0xf3/0x9c0 fscache_create_volume_work+0x97/0x150 process_one_work+0x7fa/0x1800 [...] Freed by task 120301: kfree+0xf1/0x2c0 cachefiles_withdraw_cache+0x3fa/0x920 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 do_exit+0x87a/0x29b0 [...] ================================================================== Following is the process that triggers the issue: p1 | p2 ------------------------------------------------------------ fscache_begin_lookup fscache_begin_volume_access fscache_cache_is_live(fscache_cache) cachefiles_daemon_release cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache fscache_withdraw_cache fscache_set_cache_state(cache, FSCACHE_CACHE_IS_WITHDRAWN); cachefiles_withdraw_objects(cache) fscache_wait_for_objects(fscache) atomic_read(&fscache_cache->object_count) == 0 fscache_perform_lookup cachefiles_lookup_cookie cachefiles_alloc_object refcount_set(&object->ref, 1); object->volume = volume fscache_count_object(vcookie->cache); atomic_inc(&fscache_cache->object_count) cachefiles_withdraw_volumes cachefiles_withdraw_volume fscache_withdraw_volume __cachefiles_free_volume kfree(cachefiles_volume) fscache_cookie_state_machine cachefiles_withdraw_cookie cache = object->volume->cache; // cachefiles_volume UAF !!! After setting FSCACHE_CACHE_IS_WITHDRAWN, wait for all the cookie lookups to complete first, and then wait for fscache_cache->object_count == 0 to avoid the cookie exiting after the volume has been freed and triggering the above issue. Therefore call fscache_withdraw_volume() before calling cachefiles_withdraw_objects(). This way, after setting FSCACHE_CACHE_IS_WITHDRAWN, only the following two cases will occur: 1) fscache_begin_lookup fails in fscache_begin_volume_access(). 2) fscache_withdraw_volume() will ensure that fscache_count_object() has been executed before calling fscache_wait_for_objects().

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41058
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix slab-use-after-free in fscache_withdraw_volume() We got the following issue in our fault injection stress test: ================================================================== BUG: KASAN: slab-use-after-free in fscache_withdraw_volume+0x2e1/0x370 Read of size 4 at addr ffff88810680be08 by task ondemand-04-dae/5798 CPU: 0 PID: 5798 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #565 Call Trace: kasan_check_range+0xf6/0x1b0 fscache_withdraw_volume+0x2e1/0x370 cachefiles_withdraw_volume+0x31/0x50 cachefiles_withdraw_cache+0x3ad/0x900 cachefiles_put_unbind_pincount+0x1f6/0x250 cachefiles_daemon_release+0x13b/0x290 __fput+0x204/0xa00 task_work_run+0x139/0x230 Allocated by task 5820: __kmalloc+0x1df/0x4b0 fscache_alloc_volume+0x70/0x600 __fscache_acquire_volume+0x1c/0x610 erofs_fscache_register_volume+0x96/0x1a0 erofs_fscache_register_fs+0x49a/0x690 erofs_fc_fill_super+0x6c0/0xcc0 vfs_get_super+0xa9/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 [...] Freed by task 5820: kfree+0xf1/0x2c0 fscache_put_volume.part.0+0x5cb/0x9e0 erofs_fscache_unregister_fs+0x157/0x1b0 erofs_kill_sb+0xd9/0x1c0 deactivate_locked_super+0xa3/0x100 vfs_get_super+0x105/0x140 vfs_get_tree+0x8e/0x300 do_new_mount+0x28c/0x580 [...] ================================================================== Following is the process that triggers the issue: mount failed | daemon exit ------------------------------------------------------------ deactivate_locked_super cachefiles_daemon_release erofs_kill_sb erofs_fscache_unregister_fs fscache_relinquish_volume __fscache_relinquish_volume fscache_put_volume(fscache_volume, fscache_volume_put_relinquish) zero = __refcount_dec_and_test(&fscache_volume->ref, &ref); cachefiles_put_unbind_pincount cachefiles_daemon_unbind cachefiles_withdraw_cache cachefiles_withdraw_volumes list_del_init(&volume->cache_link) fscache_free_volume(fscache_volume) cache->ops->free_volume cachefiles_free_volume list_del_init(&cachefiles_volume->cache_link); kfree(fscache_volume) cachefiles_withdraw_volume fscache_withdraw_volume fscache_volume->n_accesses // fscache_volume UAF !!! The fscache_volume in cache->volumes must not have been freed yet, but its reference count may be 0. So use the new fscache_try_get_volume() helper function try to get its reference count. If the reference count of fscache_volume is 0, fscache_put_volume() is freeing it, so wait for it to be removed from cache->volumes. If its reference count is not 0, call cachefiles_withdraw_volume() with reference count protection to avoid the above issue.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41059
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value in copy_name [syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-41060
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check bo_va->bo is non-NULL before using it The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41062
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bluetooth/l2cap: sync sock recv cb and release The problem occurs between the system call to close the sock and hci_rx_work, where the former releases the sock and the latter accesses it without lock protection. CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb If hci_rx_work processes the data that needs to be received before the sock is closed, then everything is normal; Otherwise, the work thread may access the released sock when receiving data. Add a chan mutex in the rx callback of the sock to achieve synchronization between the sock release and recv cb. Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41063
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: cancel all works upon hci_unregister_dev() syzbot is reporting that calling hci_release_dev() from hci_error_reset() due to hci_dev_put() from hci_error_reset() can cause deadlock at destroy_workqueue(), for hci_error_reset() is called from hdev->req_workqueue which destroy_workqueue() needs to flush. We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are queued into hdev->workqueue and hdev->{power_on,error_reset} which are queued into hdev->req_workqueue are no longer running by the moment destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); are called from hci_release_dev(). Call cancel_work_sync() on these work items from hci_unregister_dev() as soon as hdev->list is removed from hci_dev_list.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41064
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: avoid possible crash when edev->pdev changes If a PCI device is removed during eeh_pe_report_edev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41065
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Whitelist dtl slub object for copying to userspace Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-* results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as shown below. kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85 Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3) MSR: 8000000000029033 CR: 2828220f XER: 0000000e CFAR: c0000000001fdc80 IRQMASK: 0 [ ... GPRs omitted ... ] NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0 LR [c0000000005d23d0] usercopy_abort+0x74/0xb0 Call Trace: usercopy_abort+0x74/0xb0 (unreliable) __check_heap_object+0xf8/0x120 check_heap_object+0x218/0x240 __check_object_size+0x84/0x1a4 dtl_file_read+0x17c/0x2c4 full_proxy_read+0x8c/0x110 vfs_read+0xdc/0x3a0 ksys_read+0x84/0x144 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec --- interrupt: 3000 at 0x7fff81f3ab34 Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0") requires that only whitelisted areas in slab/slub objects can be copied to userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY. Dtl contains hypervisor dispatch events which are expected to be read by privileged users. Hence mark this safe for user access. Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the entire object.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41066
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=, skb=, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41068
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Fix sclp_init() cleanup on failure If sclp_init() fails it only partially cleans up: if there are multiple failing calls to sclp_init() sclp_state_change_event will be added several times to sclp_reg_list, which results in the following warning: ------------[ cut here ]------------ list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10. WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3 Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8 ([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30 Fix this by removing sclp_state_change_event from sclp_reg_list when sclp_init() fails.

Published: 2024-07-29Modified: 2026-01-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41069
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Fix references to freed memory Most users after parsing a topology file, release memory used by it, so having pointer references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as needed.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41070
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group() Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group(). It looks up `stt` from tablefd, but then continues to use it after doing fdput() on the returned fd. After the fdput() the tablefd is free to be closed by another thread. The close calls kvm_spapr_tce_release() and then release_spapr_tce_table() (via call_rcu()) which frees `stt`. Although there are calls to rcu_read_lock() in kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent the UAF, because `stt` is used outside the locked regions. With an artifcial delay after the fdput() and a userspace program which triggers the race, KASAN detects the UAF: BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dump_stack_lvl+0xb4/0x108 (unreliable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [kvm] rcu_core+0x568/0x16a0 handle_softirqs+0x23c/0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394/0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14 Fix it by delaying the fdput() until `stt` is no longer in use, which is effectively the entire function. To keep the patch minimal add a call to fdput() at each of the existing return paths. Future work can convert the function to goto or __cleanup style cleanup. With the fix in place the test case no longer triggers the UAF.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41072
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: wext: add extra SIOCSIWSCAN data check In 'cfg80211_wext_siwscan()', add extra check whether number of channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41073
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: nvme: avoid double free special payload If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQF_SPECIAL_LOAD when the request is cleaned.

Published: 2024-07-29Modified: 2026-01-14
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41074
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: cachefiles: Set object to close if ondemand_id < 0 in copen If copen is maliciously called in the user mode, it may delete the request corresponding to the random id. And the request may have not been read yet. Note that when the object is set to reopen, the open request will be done with the still reopen state in above case. As a result, the request corresponding to this object is always skipped in select_req function, so the read request is never completed and blocks other process. Fix this issue by simply set object to close if its id < 0 in copen.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41075
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cachefiles: add consistency check for copen/cread This prevents malicious processes from completing random copen/cread requests and crashing the system. Added checks are listed below: * Generic, copen can only complete open requests, and cread can only complete read requests. * For copen, ondemand_id must not be 0, because this indicates that the request has not been read by the daemon. * For cread, the object corresponding to fd and req should be the same.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41076
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix memory leak in nfs4_set_security_label We leak nfs_fattr and nfs4_label every time we set a security xattr.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41077
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: null_blk: fix validation of block size Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check. Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1]. [axboe: remove unnecessary braces and != 0 check]

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41078
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix quota root leak after quota disable failure If during the quota disable we fail when cleaning the quota tree or when deleting the root from the root tree, we jump to the 'out' label without ever dropping the reference on the quota root, resulting in a leak of the root since fs_info->quota_root is no longer pointing to the root (we have set it to NULL just before those steps). Fix this by always doing a btrfs_put_root() call under the 'out' label. This is a problem that exists since qgroups were first added in 2012 by commit bed92eae26cc ("Btrfs: qgroup implementation and prototypes"), but back then we missed a kfree on the quota root and free_extent_buffer() calls on its root and commit root nodes, since back then roots were not yet reference counted.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41079
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nvmet: always initialize cqe.result The spec doesn't mandate that the first two double words (aka results) for the command queue entry need to be set to 0 when they are not used (not specified). Though, the target implemention returns 0 for TCP and FC but not for RDMA. Let's make RDMA behave the same and thus explicitly initializing the result field. This prevents leaking any data from the stack.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41081
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ila: block BH in ila_output() As explained in commit 1378817486d6 ("tipc: block BH before using dst_cache"), net/core/dst_cache.c helpers need to be called with BH disabled. ila_output() is called from lwtunnel_output() possibly from process context, and under rcu_read_lock(). We might be interrupted by a softirq, re-enter ila_output() and corrupt dst_cache data structures. Fix the race by using local_bh_disable().

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41087
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Fix double free on error If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free: kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devres_open_group() call failed.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41088
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: fix infinite loop when xmit fails When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. [mkl: use more imperative wording in patch description]

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41089
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41090
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: tap: add missing verification for short frame The cited commit missed to check against the validity of the frame length in the tap_get_user_xdp() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tap_get_user_xdp()-->skb_set_network_header() may assume the size is more than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata. In the alternative path, tap_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted. This is to drop any frame shorter than the Ethernet header size just like how tap_get_user() does. CVE: CVE-2024-41090

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-41091
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: tun: add missing verification for short frame The cited commit missed to check against the validity of the frame length in the tun_xdp_one() path, which could cause a corrupted skb to be sent downstack. Even before the skb is transmitted, the tun_xdp_one-->eth_type_trans() may access the Ethernet header although it can be less than ETH_HLEN. Once transmitted, this could either cause out-of-bound access beyond the actual length, or confuse the underlayer with incorrect or inconsistent header length in the skb metadata. In the alternative path, tun_get_user() already prohibits short frame which has the length less than Ethernet header size from being transmitted for IFF_TAP. This is to drop any frame shorter than the Ethernet header size just like how tun_get_user() does. CVE: CVE-2024-41091

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-41092
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix potential UAF by revoke of fence registers CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines: <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ... In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms. Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it. The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence(). (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41093
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41095
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41096
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: PCI/MSI: Fix UAF in msi_capability_init KFENCE reports the following UAF: BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488 Use-after-free read at 0x0000000024629571 (in kfence-#12): __pci_enable_msi_range+0x2c0/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128 allocated by task 81 on cpu 7 at 10.808142s: __kmem_cache_alloc_node+0x1f0/0x2bc kmalloc_trace+0x44/0x138 msi_alloc_desc+0x3c/0x9c msi_domain_insert_msi_desc+0x30/0x78 msi_setup_msi_desc+0x13c/0x184 __pci_enable_msi_range+0x258/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 freed by task 81 on cpu 7 at 10.811436s: msi_domain_free_descs+0xd4/0x10c msi_domain_free_locked.part.0+0xc0/0x1d8 msi_domain_alloc_irqs_all_locked+0xb4/0xbc pci_msi_setup_msi_irqs+0x30/0x4c __pci_enable_msi_range+0x2a8/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 Descriptor allocation done in: __pci_enable_msi_range msi_capability_init msi_setup_msi_desc msi_insert_msi_desc msi_domain_insert_msi_desc msi_alloc_desc ... Freed in case of failure in __msi_domain_alloc_locked() __pci_enable_msi_range msi_capability_init pci_msi_setup_msi_irqs msi_domain_alloc_irqs_all_locked msi_domain_alloc_locked __msi_domain_alloc_locked => fails msi_domain_free_locked ... That failure propagates back to pci_msi_setup_msi_irqs() in msi_capability_init() which accesses the descriptor for unmasking in the error exit path. Cure it by copying the descriptor and using the copy for the error exit path unmask operation. [ tglx: Massaged change log ]

Published: 2024-07-29Modified: 2026-03-24
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-41097
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: fix endpoint checking in cxacru_bind() Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-41098
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Fix null pointer dereference on error If the ata_port_alloc() call in ata_host_alloc() fails, ata_host_release() will get called. However, the code in ata_host_release() tries to free ata_port struct members unconditionally, which can lead to the following: BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? ata_host_release.cold+0x2f/0x6e [libata] ? ata_host_release.cold+0x2f/0x6e [libata] release_nodes+0x35/0xb0 devres_release_group+0x113/0x140 ata_host_alloc+0xed/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Do not access ata_port struct members unconditionally.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42063
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode syzbot reported uninit memory usages during map_{lookup,delete}_elem. ========== BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline] bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237 ========== The reproducer should be in the interpreter mode. The C reproducer is trying to run the following bpf prog: 0: (18) r0 = 0x0 2: (18) r1 = map[id:49] 4: (b7) r8 = 16777216 5: (7b) *(u64 *)(r10 -8) = r8 6: (bf) r2 = r10 7: (07) r2 += -229 ^^^^^^^^^^ 8: (b7) r3 = 8 9: (b7) r4 = 0 10: (85) call dev_map_lookup_elem#1543472 11: (95) exit It is due to the "void *key" (r2) passed to the helper. bpf allows uninit stack memory access for bpf prog with the right privileges. This patch uses kmsan_unpoison_memory() to mark the stack as initialized. This should address different syzbot reports on the uninit "void *key" argument during map_{lookup,delete}_elem.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42067
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() set_memory_rox() can fail, leaving memory unprotected. Check return and bail out when bpf_jit_binary_lock_ro() returns an error.

Published: 2024-07-29Modified: 2025-01-24
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42068
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() set_memory_ro() can fail, leaving memory unprotected. Check its return and take it into account as an error.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42069
MEDIUM5.5

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.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42070
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42073
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems The following two shared buffer operations make use of the Shared Buffer Status Register (SBSR): # devlink sb occupancy snapshot pci/0000:01:00.0 # devlink sb occupancy clearmax pci/0000:01:00.0 The register has two masks of 256 bits to denote on which ingress / egress ports the register should operate on. Spectrum-4 has more than 256 ports, so the register was extended by cited commit with a new 'port_page' field. However, when filling the register's payload, the driver specifies the ports as absolute numbers and not relative to the first port of the port page, resulting in memory corruptions [1]. Fix by specifying the ports relative to the first port of the port page. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0 Read of size 1 at addr ffff8881068cb00f by task devlink/1566 [...] Call Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0 mlxsw_devlink_sb_occ_snapshot+0x75/0xb0 devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0 genl_family_rcv_msg_doit+0x20c/0x300 genl_rcv_msg+0x567/0x800 netlink_rcv_skb+0x170/0x450 genl_rcv+0x2d/0x40 netlink_unicast+0x547/0x830 netlink_sendmsg+0x8d4/0xdb0 __sys_sendto+0x49b/0x510 __x64_sys_sendto+0xe5/0x1c0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] Allocated by task 1: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 copy_verifier_state+0xbc2/0xfb0 do_check_common+0x2c51/0xc7e0 bpf_check+0x5107/0x9960 bpf_prog_load+0xf0e/0x2690 __sys_bpf+0x1a61/0x49d0 __x64_sys_bpf+0x7d/0xc0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 1: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x109/0x170 __kasan_slab_free+0x14/0x30 kfree+0xca/0x2b0 free_verifier_state+0xce/0x270 do_check_common+0x4828/0xc7e0 bpf_check+0x5107/0x9960 bpf_prog_load+0xf0e/0x2690 __sys_bpf+0x1a61/0x49d0 __x64_sys_bpf+0x7d/0xc0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42074
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp: add a null check for chip_pdev structure When acp platform device creation is skipped, chip->chip_pdev value will remain NULL. Add NULL check for chip->chip_pdev structure in snd_acp_resume() function to avoid null pointer dereference.

Published: 2024-07-29Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42076
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: Initialize unused data in j1939_send_one() syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one() creates full frame including unused data, but it doesn't initialize it. This causes the kernel-infoleak issue. Fix this by initializing unused data. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] memcpy_to_msg include/linux/skbuff.h:4113 [inline] raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 ____sys_recvmsg+0x18a/0x620 net/socket.c:2803 ___sys_recvmsg+0x223/0x840 net/socket.c:2845 do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1313 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 sock_alloc_send_skb include/net/sock.h:1842 [inline] j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline] j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline] j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 12-15 of 16 are uninitialized Memory access of size 16 starts at ffff888120969690 Data copied to user address 00000000200017c0 CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42077
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix DIO failure due to insufficient transaction credits The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42079
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix NULL pointer dereference in gfs2_log_flush In gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flush lock to provide exclusion against gfs2_log_flush(). In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL before dereferencing it. Otherwise, we could run into a NULL pointer dereference when outstanding glock work races with an unmount (glock_work_func -> run_queue -> do_xmote -> inode_go_sync -> gfs2_log_flush).

Published: 2024-07-29Modified: 2026-03-17
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42080
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/restrack: Fix potential invalid address access struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME in ib_create_cq(), while if the module exited but forgot del this rdma_restrack_entry, it would cause a invalid address access in rdma_restrack_clean() when print the owner of this rdma_restrack_entry. These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42082
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xdp: Remove WARN() from __xdp_reg_mem_model() syzkaller reports a warning in __xdp_reg_mem_model(). The warning occurs only if __mem_id_init_hash_table() returns an error. It returns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly. The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation. Thus, there is no sense in using WARN() to handle this error and it can be safely removed. WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Found by Linux Verification Center (linuxtesting.org) with syzkaller.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42084
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ftruncate: pass a signed offset The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB. Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL. The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
References
CVE-2024-42085
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1st dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->lock, flags); <-- 2nd This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") that removes the code of checking whether dwc->gadget_driver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42086
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: iio: chemical: bme680: Fix overflows in compensate() functions There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor"). [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42087
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42089
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl-asoc-card: set priv->pdev before using it priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42090
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42092
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: gpio: davinci: Validate the obtained number of IRQs Value of pdata->gpio_unbanked is taken from Device Tree. In case of broken DT due to any error this value can be any. Without this value validation there can be out of chips->irqs array boundaries access in davinci_gpio_probe(). Validate the obtained nirq value so that it won't exceed the maximum number of IRQs per bank. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42093
HIGH7.3

In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H
References
CVE-2024-42094
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: net/iucv: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-42095
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: serial: 8250_omap: Implementation of Errata i2310 As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution. [0] https://www.ti.com/lit/pdf/sprz536 page 23

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42096
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days. And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF. which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addresses but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame. It causes KASAN unhappiness reported for years by syzkaller [1] and others [2]. With no real practical reason for this any more, just remove the code. Just for historical interest, here's some background commits relating to this code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64") and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc") but the basics of this thing actually goes back to before the git tree.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42097
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42098
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: ecdh - explicitly zeroize private_key private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire private_key array first. Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey failed, the old private_key would remain. Now, the private_key is always zeroized. This behavior is consistent with the case where params.key is set and ecc_is_key_valid fails.

Published: 2024-07-29Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42101
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42104
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: nilfs2: add missing check for inode numbers on directory entries Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking. Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages. Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42105
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix inode number range checks Patch series "nilfs2: fix potential issues related to reserved inodes". This series fixes one use-after-free issue reported by syzbot, caused by nilfs2's internal inode being exposed in the namespace on a corrupted filesystem, and a couple of flaws that cause problems if the starting number of non-reserved inodes written in the on-disk super block is intentionally (or corruptly) changed from its default value. This patch (of 3): In the current implementation of nilfs2, "nilfs->ns_first_ino", which gives the first non-reserved inode number, is read from the superblock, but its lower limit is not checked. As a result, if a number that overlaps with the inode number range of reserved inodes such as the root directory or metadata files is set in the super block parameter, the inode number test macros (NILFS_MDT_INODE and NILFS_VALID_INODE) will not function properly. In addition, these test macros use left bit-shift calculations using with the inode number as the shift count via the BIT macro, but the result of a shift calculation that exceeds the bit width of an integer is undefined in the C specification, so if "ns_first_ino" is set to a large value other than the default value NILFS_USER_INO (=11), the macros may potentially malfunction depending on the environment. Fix these issues by checking the lower bound of "nilfs->ns_first_ino" and by preventing bit shifts equal to or greater than the NILFS_USER_INO constant in the inode number test macros. Also, change the type of "ns_first_ino" from signed integer to unsigned integer to avoid the need for type casting in comparisons such as the lower bound check introduced this time.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42106
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: inet_diag: Initialize pad field in struct inet_diag_req_v2 KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw. inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field. Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future. [1] BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42109
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: unconditionally flush pending work before notifier syzbot reports: KASAN: slab-uaf in nft_ctx_update include/net/netfilter/nf_tables.h:1831 KASAN: slab-uaf in nft_commit_release net/netfilter/nf_tables_api.c:9530 KASAN: slab-uaf int nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Read of size 2 at addr ffff88802b0051c4 by task kworker/1:1/45 [..] Workqueue: events nf_tables_trans_destroy_work Call Trace: nft_ctx_update include/net/netfilter/nf_tables.h:1831 [inline] nft_commit_release net/netfilter/nf_tables_api.c:9530 [inline] nf_tables_trans_destroy_work+0x152b/0x1750 net/netfilter/nf_tables_api.c:9597 Problem is that the notifier does a conditional flush, but its possible that the table-to-be-removed is still referenced by transactions being processed by the worker, so we need to flush unconditionally. We could make the flush_work depend on whether we found a table to delete in nf-next to avoid the flush for most cases. AFAICS this problem is only exposed in nf-next, with commit e169285f8c56 ("netfilter: nf_tables: do not store nft_ctx in transaction objects"), with this commit applied there is an unconditional fetch of table->family which is whats triggering the above splat.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42110
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx() The following is emitted when using idxd (DSA) dmanegine as the data mover for ntb_transport that ntb_netdev uses. [74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526 [74412.556784] caller is netif_rx_internal+0x42/0x130 [74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5 [74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024 [74412.581699] Call Trace: [74412.584514] [74412.586933] dump_stack_lvl+0x55/0x70 [74412.591129] check_preemption_disabled+0xc8/0xf0 [74412.596374] netif_rx_internal+0x42/0x130 [74412.600957] __netif_rx+0x20/0xd0 [74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev] [74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport] [74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport] [74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd] [74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd] [74412.634046] irq_thread_fn+0x21/0x60 [74412.638134] ? irq_thread+0xa8/0x290 [74412.642218] irq_thread+0x1a0/0x290 [74412.646212] ? __pfx_irq_thread_fn+0x10/0x10 [74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10 [74412.656117] ? __pfx_irq_thread+0x10/0x10 [74412.660686] kthread+0x100/0x130 [74412.664384] ? __pfx_kthread+0x10/0x10 [74412.668639] ret_from_fork+0x31/0x50 [74412.672716] ? __pfx_kthread+0x10/0x10 [74412.676978] ret_from_fork_asm+0x1a/0x30 [74412.681457] The cause is due to the idxd driver interrupt completion handler uses threaded interrupt and the threaded handler is not hard or soft interrupt context. However __netif_rx() can only be called from interrupt context. Change the call to netif_rx() in order to allow completion via normal context for dmaengine drivers that utilize threaded irq handling. While the following commit changed from netif_rx() to __netif_rx(), baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."), the change should've been a noop instead. However, the code precedes this fix should've been using netif_rx_ni() or netif_rx_any_context().

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42114
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM to 2^31. We had a similar issue in sch_fq, fixed with commit d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM") watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini ---truncated---

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42115
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: jffs2: Fix potential illegal address access in jffs2_free_inode During the stress testing of the jffs2 file system,the following abnormal printouts were found: [ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948 [ 2430.649622] Mem abort info: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: level 0 translation fault [ 2430.651446] Data abort info: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] address between user and kernel address ranges [ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33 [ 2430.655008] Hardware name: linux,dummy-virt (DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051] sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19 [ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14 [ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302 [ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342 [ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000 [ 2430.664217] Call trace: [ 2430.664528] kfree+0x78/0x348 [ 2430.664855] jffs2_free_inode+0x24/0x48 [ 2430.665233] i_callback+0x24/0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] __do_softirq+0x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of the jffs_inode_info structure. It was found that all variables in the jffs_inode_info structure were 5a5a5a5a, except for the first member sem. It is suspected that these variables are not initialized because they were set to 5a5a5a5a during memory testing, which is meant to detect uninitialized memory.The sem variable is initialized in the function jffs2_i_init_once, while other members are initialized in the function jffs2_init_inode_info. The function jffs2_init_inode_info is called after iget_locked, but in the iget_locked function, the destroy_inode process is triggered, which releases the inode and consequently, the target member of the inode is not initialized.In concurrent high pressure scenarios, iget_locked may enter the destroy_inode branch as described in the code. Since the destroy_inode functionality of jffs2 only releases the target, the fix method is to set target to NULL in jffs2_i_init_once.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42119
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip finding free audio for unknown engine_id [WHY] ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio. [HOW] Skip and return NULL. This fixes 2 OVERRUN issues reported by Coverity.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42120
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check pipe offset before setting vblank pipe_ctx has a size of MAX_PIPES so checking its index before accessing the array. This fixes an OVERRUN issue reported by Coverity.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42121
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check index msg_id before read or write [WHAT] msg_id is used as an array index and it cannot be a negative value, and therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1). [HOW] Check whether msg_id is valid before reading and setting. This fixes 4 OVERRUN issues reported by Coverity.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42124
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Make qedf_execute_tmf() non-preemptible Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel. [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42126
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt. nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel crash when invoked during real mode interrupt handling (e.g. early HMI/MCE interrupt handler) if percpu allocation comes from vmalloc area. Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI() wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when percpu allocation is from the embedded first chunk. However with CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu allocation can come from the vmalloc area. With kernel command line "percpu_alloc=page" we can force percpu allocation to come from vmalloc area and can see kernel crash in machine_check_early: [ 1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110 [ 1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0 [ 1.215719] --- interrupt: 200 [ 1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable) [ 1.215722] [c000000fffd731b0] [0000000000000000] 0x0 [ 1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8 Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu first chunk is not embedded.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42127
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix shared irq handling on driver remove lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42128
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: leds: an30259a: Use devm_mutex_init() for mutex initialization In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.

Published: 2024-07-30Modified: 2025-09-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42131
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: mm: avoid overflows in dirty throttling logic The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX. This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42135
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: vhost_task: Handle SIGKILL by flushing work and exiting Instead of lingering until the device is closed, this has us handle SIGKILL by: 1. marking the worker as killed so we no longer try to use it with new virtqueues and new flush operations. 2. setting the virtqueue to worker mapping so no new works are queued. 3. running all the exiting works.

Published: 2024-07-30Modified: 2024-12-11
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42136
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: cdrom: rearrange last_media_change check to avoid unintentional overflow When running syzkaller with the newly reintroduced signed integer wrap sanitizer we encounter this splat: [ 366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33 [ 366.021089] -9223372036854775808 - 346321 cannot be represented in type '__s64' (aka 'long long') [ 366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO [ 366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [ 366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 366.027518] Call Trace: [ 366.027523] [ 366.027533] dump_stack_lvl+0x93/0xd0 [ 366.027899] handle_overflow+0x171/0x1b0 [ 366.038787] ata1.00: invalid multi_count 32 ignored [ 366.043924] cdrom_ioctl+0x2c3f/0x2d10 [ 366.063932] ? __pm_runtime_resume+0xe6/0x130 [ 366.071923] sr_block_ioctl+0x15d/0x1d0 [ 366.074624] ? __pfx_sr_block_ioctl+0x10/0x10 [ 366.077642] blkdev_ioctl+0x419/0x500 [ 366.080231] ? __pfx_blkdev_ioctl+0x10/0x10 ... Historically, the signed integer overflow sanitizer did not work in the kernel due to its interaction with `-fwrapv` but this has since been changed [1] in the newest version of Clang. It was re-enabled in the kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow sanitizer"). Let's rearrange the check to not perform any arithmetic, thus not tripping the sanitizer.

Published: 2024-07-30Modified: 2026-03-24
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42137
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev") will cause below regression issue: BT can't be enabled after below steps: cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure if property enable-gpios is not configured within DT|ACPI for QCA6390. The commit is to fix a use-after-free issue within qca_serdev_shutdown() by adding condition to avoid the serdev is flushed or wrote after closed but also introduces this regression issue regarding above steps since the VSC is not sent to reset controller during warm reboot. Fixed by sending the VSC to reset controller within qca_serdev_shutdown() once BT was ever enabled, and the use-after-free issue is also fixed by this change since the serdev is still opened before it is flushed or wrote. Verified by the reported machine Dell XPS 13 9310 laptop over below two kernel commits: commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of bluetooth-next tree. commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump implementation for QCA") of linus mainline tree.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42138
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: mlxsw: core_linecards: Fix double memory deallocation in case of invalid INI file In case of invalid INI file mlxsw_linecard_types_init() deallocates memory but doesn't reset pointer to NULL and returns 0. In case of any error occurred after mlxsw_linecard_types_init() call, mlxsw_linecards_init() calls mlxsw_linecard_types_fini() which performs memory deallocation again. Add pointer reset to NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42140
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: riscv: kexec: Avoid deadlock in kexec crash path If the kexec crash code is called in the interrupt context, the machine_kexec_mask_interrupts() function will trigger a deadlock while trying to acquire the irqdesc spinlock and then deactivate irqchip in irq_set_irqchip_state() function. Unlike arm64, riscv only requires irq_eoi handler to complete EOI and keeping irq_set_irqchip_state() will only leave this possible deadlock without any use. So we simply remove it.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42142
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: E-switch, Create ingress ACL when needed Currently, ingress acl is used for three features. It is created only when vport metadata match and prio tag are enabled. But active-backup lag mode also uses it. It is independent of vport metadata match and prio tag. And vport metadata match can be disabled using the following devlink command: # devlink dev param set pci/0000:08:00.0 name esw_port_metadata \ value false cmode runtime If ingress acl is not created, will hit panic when creating drop rule for active-backup lag mode. If always create it, there will be about 5% performance degradation. Fix it by creating ingress acl when needed. If esw_port_metadata is true, ingress acl exists, then create drop rule using existing ingress acl. If esw_port_metadata is false, create ingress acl and then create drop rule.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42144
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data Verify that lvts_data is not NULL before using it.

Published: 2024-07-30Modified: 2024-11-21
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42145
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: IB/core: Implement a limit on UMAD receive List The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42147
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/debugfs - Fix debugfs uninit process issue During the zip probe process, the debugfs failure does not stop the probe. When debugfs initialization fails, jumping to the error branch will also release regs, in addition to its own rollback operation. As a result, it may be released repeatedly during the regs uninit process. Therefore, the null check needs to be added to the regs uninit process.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42148
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bnx2x: Fix multiple UBSAN array-index-out-of-bounds Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter. Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array: struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX]; FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not. This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch /* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */ However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below. This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs. Stack traces: UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42152
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42153
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42154
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated).

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
References
CVE-2024-42157
MEDIUM4.1

In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Wipe sensitive data on failure Wipe sensitive data from stack also if the copy_to_user() fails.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 4.1
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-42159
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed.

Published: 2024-07-30Modified: 2026-03-25
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42160
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code.

Published: 2024-07-30Modified: 2026-03-25
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42161
MEDIUM6.3

In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD [Changes from V1: - Use a default branch in the switch statement to initialize `val'.] GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 6.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:H
References
CVE-2024-42223
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: tda10048: Fix integer overflow state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pll_mfactor. Create a new 64 bit variable to hold the calculations.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42224
MEDIUM6.1

In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 6.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
References
CVE-2024-42225
HIGH7.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: replace skb_put with skb_put_zero Avoid potentially reusing uninitialized data

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42228
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42229
MEDIUM4.1

In the Linux kernel, the following vulnerability has been resolved: crypto: aead,cipher - zeroize key buffer after use I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 4.1
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-42230
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all.

Published: 2024-07-30Modified: 2025-11-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42232
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42236
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form `if (str[0 - 1] == '\n') followed closely by an OOB write in the form `str[0 - 1] = '\0'`. There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short.

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42237
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Validate payload length before processing block Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it.

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42238
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Return error if block header overflows file Return an error from cs_dsp_power_up() if a block header is longer than the amount of data left in the file. The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loop while there was enough data left in the file for a valid region. This protected against overrunning the end of the file data, but it didn't abort the file processing with an error.

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42239
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors. Background on prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status. It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another option was explored where bpf_timer_start would clear the bit when (re)starting the timer under timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared before in-flight hrtimer_cancel has finished executing, such that lockups can occur again. Thus, we choose an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in case callbacks attempt to cancel each other while executing in parallel.

Published: 2024-08-07Modified: 2024-08-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42240
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/bhi: Avoid warning in #DB handler due to BHI mitigation When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set then entry_SYSENTER_compat() uses CLEAR_BRANCH_HISTORY and calls the clear_bhb_loop() before the TF flag is cleared. This causes the #DB handler (exc_debug_kernel()) to issue a warning because single-step is used outside the entry_SYSENTER_compat() function. To address this issue, entry_SYSENTER_compat() should use CLEAR_BRANCH_HISTORY after making sure the TF flag is cleared. The problem can be reproduced with the following sequence: $ cat sysenter_step.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); } $ gcc -o sysenter_step sysenter_step.c $ ./sysenter_step Segmentation fault (core dumped) The program is expected to crash, and the #DB handler will issue a warning. Kernel log: WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 exc_debug_kernel+0xd2/0x160 ... RIP: 0010:exc_debug_kernel+0xd2/0x160 ... Call Trace: <#DB> ? show_regs+0x68/0x80 ? __warn+0x8c/0x140 ? exc_debug_kernel+0xd2/0x160 ? report_bug+0x175/0x1a0 ? handle_bug+0x44/0x90 ? exc_invalid_op+0x1c/0x70 ? asm_exc_invalid_op+0x1f/0x30 ? exc_debug_kernel+0xd2/0x160 exc_debug+0x43/0x50 asm_exc_debug+0x1e/0x40 RIP: 0010:clear_bhb_loop+0x0/0xb0 ... ? entry_SYSENTER_compat_after_hwframe+0x6e/0x8d [ bp: Massage commit message. ]

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42241
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/shmem: disable PMD-sized page cache if needed For shmem files, it's possible that PMD-sized page cache can't be supported by xarray. For example, 512MB page cache on ARM64 when the base page size is 64KB can't be supported by xarray. It leads to errors as the following messages indicate when this sort of xarray entry is split. WARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 \ nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject \ nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs \ libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \ net_failover virtio_console virtio_blk failover dimlib virtio_mmio CPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff8000882af5f0 x29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768 x26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858 x23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0 x5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace: xas_split_alloc+0xf8/0x128 split_huge_page_to_list_to_order+0x1c4/0x720 truncate_inode_partial_folio+0xdc/0x160 shmem_undo_range+0x2bc/0x6a8 shmem_fallocate+0x134/0x430 vfs_fallocate+0x124/0x2e8 ksys_fallocate+0x4c/0xa0 __arm64_sys_fallocate+0x24/0x38 invoke_syscall.constprop.0+0x7c/0xd8 do_el0_svc+0xb4/0xd0 el0_svc+0x44/0x1d8 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Fix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger than MAX_PAGECACHE_ORDER. As Matthew Wilcox pointed, the page cache in a shmem file isn't represented by a multi-index entry and doesn't have this limitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache").

Published: 2024-08-07Modified: 2024-08-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42243
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray Patch series "mm/filemap: Limit page cache size to that supported by xarray", v2. Currently, xarray can't support arbitrary page cache size. More details can be found from the WARN_ON() statement in xas_split_alloc(). In our test whose code is attached below, we hit the WARN_ON() on ARM64 system where the base page size is 64KB and huge page size is 512MB. The issue was reported long time ago and some discussions on it can be found here [1]. [1] https://www.spinics.net/lists/linux-xfs/msg75404.html In order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one supported by xarray and avoid PMD-sized page cache if needed. The code changes are suggested by David Hildenbrand. PATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path PATCH[4] avoids PMD-sized page cache for shmem files if needed Test program ============ # cat test.c #define _GNU_SOURCE #include #include #include #include #include #include #include #include #define TEST_XFS_FILENAME "/tmp/data" #define TEST_SHMEM_FILENAME "/dev/shm/data" #define TEST_MEM_SIZE 0x20000000 int main(int argc, char **argv) { const char *filename; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret; if (pgsize != 0x10000) { fprintf(stderr, "64KB base page size is required\n"); return -EPERM; } system("echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled"); system("rm -fr /tmp/data"); system("rm -fr /dev/shm/data"); system("echo 1 > /proc/sys/vm/drop_caches"); /* Open xfs or shmem file */ filename = TEST_XFS_FILENAME; if (argc > 1 && !strcmp(argv[1], "shmem")) filename = TEST_SHMEM_FILENAME; fd = open(filename, O_CREAT | O_RDWR | O_TRUNC); if (fd < 0) { fprintf(stderr, "Unable to open <%s>\n", filename); return -EIO; } /* Extend file size */ ret = ftruncate(fd, TEST_MEM_SIZE); if (ret) { fprintf(stderr, "Error %d to ftruncate()\n", ret); goto cleanup; } /* Create VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (buf == (void *)-1) { fprintf(stderr, "Unable to mmap <%s>\n", filename); goto cleanup; } fprintf(stdout, "mapped buffer at 0x%p\n", buf); ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); if (ret) { fprintf(stderr, "Unable to madvise(MADV_HUGEPAGE)\n"); goto cleanup; } /* Populate VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE); if (ret) { fprintf(stderr, "Error %d to madvise(MADV_POPULATE_WRITE)\n", ret); goto cleanup; } /* Punch the file to enforce xarray split */ ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, TEST_MEM_SIZE - pgsize, pgsize); if (ret) fprintf(stderr, "Error %d to fallocate()\n", ret); cleanup: if (buf != (void *)-1) munmap(buf, TEST_MEM_SIZE); if (fd > 0) close(fd); return 0; } # gcc test.c -o test # cat /proc/1/smaps | grep KernelPageSize | head -n 1 KernelPageSize: 64 kB # ./test shmem : ------------[ cut here ]------------ WARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon \ drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \ virtio_net sha1_ce net_failover failover virtio_console virtio_blk \ dimlib virtio_mmio CPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TC ---truncated---

Published: 2024-08-07Modified: 2024-08-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42244
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: USB: serial: mos7840: fix crash on resume Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one. This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure. Fix this by implementing dedicated suspend and resume functions for mos7840. Tested with Delock 87414 USB 2.0 to 4x serial adapter. [ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42245
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Revert "sched/fair: Make sure to try to detach at least one movable task" This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06. b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if all tasks examined to that point were pinned. The goal of the patch was to make it more likely to be able to detach a task buried in a long list of pinned tasks. However, this has the unfortunate side effect of creating an O(n) iteration in detach_tasks(), as we now must fully iterate every task on a cpu if all or most are pinned. Since this load balance code is done with rq lock held, and often in softirq context, it is very easy to trigger hard lockups. We observed such hard lockups with a user who affined O(10k) threads to a single cpu. When I discussed this with Vincent he initially suggested that we keep the limit on the number of tasks to detach, but increase the number of tasks we can search. However, after some back and forth on the mailing list, he recommended we instead revert the original patch, as it seems likely no one was actually getting hit by the original issue.

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42246
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up. Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN. ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request().

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42247
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wireguard: allowedips: avoid unaligned 64-bit memory accesses On the parisc platform, the kernel issues kernel warnings because swap_endian() tries to load a 128-bit IPv6 address from an unaligned memory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc) Avoid such unaligned memory accesses by instead using the get_unaligned_be64() helper macro. [Jason: replace src[8] in original patch with src+8]

Published: 2024-08-07Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42253
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock race Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races. The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs(). The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0

Published: 2024-08-08Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42259
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)

Published: 2024-08-14Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42265
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: protect the fetch of ->fd[fd] in do_dup2() from mispredictions both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42267
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error() Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42268
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix missing lock on sync reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50 … CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116 Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50 … Call Trace: ? __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? devl_assert_locked+0x3e/0x50 devlink_notify+0x88/0x2b0 ? mlx5_attach_device+0x20c/0x230 [mlx5_core] ? __pfx_devlink_notify+0x10/0x10 ? process_one_work+0x4b6/0xbb0 process_one_work+0x4b6/0xbb0 […]

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42269
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: iptables: Fix potential null-ptr-deref in ip6table_nat_table_init(). ip6table_nat_table_init() accesses net->gen->ptr[ip6table_nat_net_ops.id], but the function is exposed to user space before the entry is allocated via register_pernet_subsys(). Let's call register_pernet_subsys() before xt_register_template().

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42270
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init(). We had a report that iptables-restore sometimes triggered null-ptr-deref at boot time. [0] The problem is that iptable_nat_table_init() is exposed to user space before the kernel fully initialises netns. In the small race window, a user could call iptable_nat_table_init() that accesses net_generic(net, iptable_nat_net_id), which is available only after registering iptable_nat_net_ops. Let's call register_pernet_subsys() before xt_register_template(). [0]: bpfilter: Loaded bpfilter_umh pid 11702 Started bpfilter BUG: kernel NULL pointer dereference, address: 0000000000000013 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page PGD 0 P4D 0 PREEMPT SMP NOPTI CPU: 2 PID: 11879 Comm: iptables-restor Not tainted 6.1.92-99.174.amzn2023.x86_64 #1 Hardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat Code: 10 4c 89 f6 48 89 ef e8 0b 19 bb ff 41 89 c4 85 c0 75 38 41 83 c7 01 49 83 c6 28 41 83 ff 04 75 dc 48 8b 44 24 08 48 8b 0c 24 <48> 89 08 4c 89 ef e8 a2 3b a2 cf 48 83 c4 10 44 89 e0 5b 5d 41 5c RSP: 0018:ffffbef902843cd0 EFLAGS: 00010246 RAX: 0000000000000013 RBX: ffff9f4b052caa20 RCX: ffff9f4b20988d80 RDX: 0000000000000000 RSI: 0000000000000064 RDI: ffffffffc04201c0 RBP: ffff9f4b29394000 R08: ffff9f4b07f77258 R09: ffff9f4b07f77240 R10: 0000000000000000 R11: ffff9f4b09635388 R12: 0000000000000000 R13: ffff9f4b1a3c6c00 R14: ffff9f4b20988e20 R15: 0000000000000004 FS: 00007f6284340000(0000) GS:ffff9f51fe280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000013 CR3: 00000001d10a6005 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? xt_find_table_lock (net/netfilter/x_tables.c:1259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? page_fault_oops (arch/x86/mm/fault.c:727) ? exc_page_fault (./arch/x86/include/asm/irqflags.h:40 ./arch/x86/include/asm/irqflags.h:75 arch/x86/mm/fault.c:1470 arch/x86/mm/fault.c:1518) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:570) ? iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat xt_find_table_lock (net/netfilter/x_tables.c:1259) xt_request_find_table_lock (net/netfilter/x_tables.c:1287) get_info (net/ipv4/netfilter/ip_tables.c:965) ? security_capable (security/security.c:809 (discriminator 13)) ? ns_capable (kernel/capability.c:376 kernel/capability.c:397) ? do_ipt_get_ctl (net/ipv4/netfilter/ip_tables.c:1656) ? bpfilter_send_req (net/bpfilter/bpfilter_kern.c:52) bpfilter nf_getsockopt (net/netfilter/nf_sockopt.c:116) ip_getsockopt (net/ipv4/ip_sockglue.c:1827) __sys_getsockopt (net/socket.c:2327) __x64_sys_getsockopt (net/socket.c:2342 net/socket.c:2339 net/socket.c:2339) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:81) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) RIP: 0033:0x7f62844685ee Code: 48 8b 0d 45 28 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 09 RSP: 002b:00007ffd1f83d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 00007ffd1f83d680 RCX: 00007f62844685ee RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 0000000000000004 R08: 00007ffd1f83d670 R09: 0000558798ffa2a0 R10: 00007ffd1f83d680 R11: 0000000000000246 R12: 00007ffd1f83e3b2 R13: 00007f6284 ---truncated---

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42271
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use after free in iucv_sock_close() iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn(). Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing. Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv. B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42273
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: assign CURSEG_ALL_DATA_ATGC if blkaddr is valid mkdir /mnt/test/comp f2fs_io setflags compression /mnt/test/comp dd if=/dev/zero of=/mnt/test/comp/testfile bs=16k count=1 truncate --size 13 /mnt/test/comp/testfile In the above scenario, we can get a BUG_ON. kernel BUG at fs/f2fs/segment.c:3589! Call Trace: do_write_page+0x78/0x390 [f2fs] f2fs_outplace_write_data+0x62/0xb0 [f2fs] f2fs_do_write_data_page+0x275/0x740 [f2fs] f2fs_write_single_data_page+0x1dc/0x8f0 [f2fs] f2fs_write_multi_pages+0x1e5/0xae0 [f2fs] f2fs_write_cache_pages+0xab1/0xc60 [f2fs] f2fs_write_data_pages+0x2d8/0x330 [f2fs] do_writepages+0xcf/0x270 __writeback_single_inode+0x44/0x350 writeback_sb_inodes+0x242/0x530 __writeback_inodes_wb+0x54/0xf0 wb_writeback+0x192/0x310 wb_workfn+0x30d/0x400 The reason is we gave CURSEG_ALL_DATA_ATGC to COMPR_ADDR where the page was set the gcing flag by set_cluster_dirty().

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42274
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Revert "ALSA: firewire-lib: operate for period elapse event in process context" Commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event in process context") removed the process context workqueue from amdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove its overhead. With RME Fireface 800, this lead to a regression since Kernels 5.14.0, causing an AB/BA deadlock competition for the substream lock with eventual system freeze under ALSA operation: thread 0: * (lock A) acquire substream lock by snd_pcm_stream_lock_irq() in snd_pcm_status64() * (lock B) wait for tasklet to finish by calling tasklet_unlock_spin_wait() in tasklet_disable_in_atomic() in ohci_flush_iso_completions() of ohci.c thread 1: * (lock B) enter tasklet * (lock A) attempt to acquire substream lock, waiting for it to be released: snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed() in update_pcm_pointers() in process_ctx_payloads() in process_rx_packets() of amdtp-stream.c ? tasklet_unlock_spin_wait ohci_flush_iso_completions firewire_ohci amdtp_domain_stream_pcm_pointer snd_firewire_lib snd_pcm_update_hw_ptr0 snd_pcm snd_pcm_status64 snd_pcm ? native_queued_spin_lock_slowpath _raw_spin_lock_irqsave snd_pcm_period_elapsed snd_pcm process_rx_packets snd_firewire_lib irq_target_callback snd_firewire_lib handle_it_packet firewire_ohci context_tasklet firewire_ohci Restore the process context work queue to prevent deadlock AB/BA deadlock competition for ALSA substream lock of snd_pcm_stream_lock_irq() in snd_pcm_status64() and snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed(). revert commit 7ba5ca32fe6e ("ALSA: firewire-lib: operate for period elapse event in process context") Replace inline description to prevent future deadlock.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42276
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nvme-pci: add missing condition check for existence of mapped data nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42279
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer While transmitting with rx_len == 0, the RX FIFO is not going to be emptied in the interrupt handler. A subsequent transfer could then read crap from the previous transfer out of the RX FIFO into the start RX buffer. The core provides a register that will empty the RX and TX FIFOs, so do that before each transfer.

Published: 2024-08-17Modified: 2025-10-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42280
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix a use after free in hfcmulti_tx() Don't dereference *sp after calling dev_kfree_skb(*sp).

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42281
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a segment issue when downgrading gso_size Linearize the skb when downgrading gso_size because it may trigger a BUG_ON() later when the skb is segmented as described in [1,2].

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42283
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: nexthop: Initialize all fields in dumped nexthops struct nexthop_grp contains two reserved fields that are not initialized by nla_put_nh_group(), and carry garbage. This can be observed e.g. with strace (edited for clarity): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len=12, nla_type=NHA_GROUP}, [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52 The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42284
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: tipc: Return non-zero value from tipc_udp_addr2str() on error tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42285
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix a use-after-free related to destroying CM IDs iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler; rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42286
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: validate nvme_local_port correctly The driver load failed with error message, qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef and with a kernel crash, BUG: unable to handle kernel NULL pointer dereference at 0000000000000070 Workqueue: events_unbound qla_register_fcport_fn [qla2xxx] RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc] RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000 RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000 RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030 R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4 R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8 FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0 Call Trace: qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx] ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx] qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx] qla_register_fcport_fn+0x54/0xc0 [qla2xxx] Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42287
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Complete command early within lock A crash was observed while performing NPIV and FW reset, BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 1 PREEMPT_RT SMP NOPTI RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? page_fault_oops+0x16f/0x4a0 ? do_user_addr_fault+0x174/0x7f0 ? exc_page_fault+0x69/0x1a0 ? asm_exc_page_fault+0x22/0x30 ? dma_direct_unmap_sg+0x51/0x1e0 ? preempt_count_sub+0x96/0xe0 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx] qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx] __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx] The command completion was done early while aborting the commands in driver unload path but outside lock to avoid the WARN_ON condition of performing dma_free_attr within the lock. However this caused race condition while command completion via multiple paths causing system crash. Hence complete the command early in unload path but within the lock to avoid race condition.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42288
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix for possible memory corruption Init Control Block is dereferenced incorrectly. Correctly dereference ICB

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42289
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: During vport delete send async logout explicitly During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting. BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? dequeue_entity+0x100/0x3c0 ? qla24xx_process_response_queue+0x6a1/0x19e0 ? __schedule+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? process_one_work+0x267/0x440 ? process_one_work+0x440/0x440 ? worker_thread+0x2d/0x3d0 ? process_one_work+0x440/0x440 ? kthread+0x156/0x180 ? set_kthread_struct+0x50/0x50 ? ret_from_fork+0x22/0x30 Send out async logout explicitly for all the ports during vport delete.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42290
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: irqchip/imx-irqsteer: Handle runtime power management correctly The power domain is automatically activated from clk_prepare(). However, on certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes sleeping functions, which triggers the 'scheduling while atomic' bug in the context switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0 Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip callbacks and handle power management in them as they are invoked from non-atomic context. [ tglx: Rewrote change log, added Fixes tag ]

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42291
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ice: Add a per-VF limit on number of FDIR filters While the iavf driver adds a s/w limit (128) on the number of FDIR filters that the VF can request, a malicious VF driver can request more than that and exhaust the resources for other VFs. Add a similar limit in ice.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42292
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: kobject_uevent: Fix OOB access within zap_modalias_env() zap_modalias_env() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-42295
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: handle inconsistent state in nilfs_btnode_create_block() Syzbot reported that a buffer state inconsistency was detected in nilfs_btnode_create_block(), triggering a kernel bug. It is not appropriate to treat this inconsistency as a bug; it can occur if the argument block address (the buffer index of the newly created block) is a virtual block number and has been reallocated due to corruption of the bitmap used to manage its allocation state. So, modify nilfs_btnode_create_block() and its callers to treat it as a possible filesystem error, rather than triggering a kernel bug.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42296
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix return value of f2fs_convert_inline_inode() If device is readonly, make f2fs_convert_inline_inode() return EROFS instead of zero, otherwise it may trigger panic during writeback of inline inode's dirty page as below: f2fs_write_single_data_page+0xbb6/0x1e90 fs/f2fs/data.c:2888 f2fs_write_cache_pages fs/f2fs/data.c:3187 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3342 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3369 do_writepages+0x359/0x870 mm/page-writeback.c:2634 filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397 __filemap_fdatawrite_range mm/filemap.c:430 [inline] file_write_and_wait_range+0x1aa/0x290 mm/filemap.c:788 f2fs_do_sync_file+0x68a/0x1ae0 fs/f2fs/file.c:276 generic_write_sync include/linux/fs.h:2806 [inline] f2fs_file_write_iter+0x7bd/0x24e0 fs/f2fs/file.c:4977 call_write_iter include/linux/fs.h:2114 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42297
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't dirty inode for readonly filesystem syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode().

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42299
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page().

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42301
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: dev/parport: fix the array out-of-bounds risk Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport]

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42302
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal Keith reports a use-after-free when a DPC event occurs concurrently to hot-removal of the same portion of the hierarchy: The dpc_handler() awaits readiness of the secondary bus below the Downstream Port where the DPC event occurred. To do so, it polls the config space of the first child device on the secondary bus. If that child device is concurrently removed, accesses to its struct pci_dev cause the kernel to oops. That's because pci_bridge_wait_for_secondary_bus() neglects to hold a reference on the child device. Before v6.3, the function was only called on resume from system sleep or on runtime resume. Holding a reference wasn't necessary back then because the pciehp IRQ thread could never run concurrently. (On resume from system sleep, IRQs are not enabled until after the resume_noirq phase. And runtime resume is always awaited before a PCI device is removed.) However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset"), which introduced that, failed to appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a reference on the child device because dpc_handler() and pciehp may indeed run concurrently. The commit was backported to v5.10+ stable kernels, so that's the oldest one affected. Add the missing reference acquisition. Abridged stack trace: BUG: unable to handle page fault for address: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pci_bus_read_config_dword+0x17/0x50 pci_dev_wait() pci_bridge_wait_for_secondary_bus() dpc_reset_link() pcie_do_recovery() dpc_handler()

Published: 2024-08-17Modified: 2026-03-27
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42304
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: make sure the first directory block is not a hole The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow. ext4_mknod ... ext4_add_entry // Read block 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // The first directory block is a hole // But type == DIRENT, so no error is reported. After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash. Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42305
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: check dot and dotdot of dx_root before making dir indexed Syzbot reports a issue as follows: ============================================ BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================ The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295] The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called. But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows: bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024 So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called. In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1. Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42306
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: udf: Avoid using corrupted block bitmap buffer When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42309
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42310
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42311
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode() Syzbot reports uninitialized value access issue as below: loop0: detected capacity change from 0 to 64 ===================================================== BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [inline] lookup_fast+0x89e/0x8e0 fs/namei.c:1649 walk_component fs/namei.c:2001 [inline] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c:2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [inline] do_mount fs/namespace.c:3689 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline] BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 hfs_ext_read_extent fs/hfs/extent.c:196 [inline] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [inline] read_cache_page+0xfb/0x2f0 mm/filemap.c:3604 read_mapping_page include/linux/pagemap.h:755 [inline] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0x2d7/0x1400 mm/slub.c:2407 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [inline] hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [inline] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:4164 [inline] __se_sys_mkdirat fs/namei.c:4162 [inline] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b It missed to initialize .tz_secondswest, .cached_start and .cached_blocks fields in struct hfs_inode_info after hfs_alloc_inode(), fix it.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42312
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sysctl: always initialize i_uid/i_gid Always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them. Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values of i_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid when set_ownership() was not implemented. It also missed adjusting net_ctl_set_ownership() to use the same default values in case the computation of a better value failed.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42313
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free in vdec_close There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42314
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix extent map use-after-free when adding pages to compressed bio At add_ra_bio_pages() we are accessing the extent map to calculate 'add_size' after we dropped our reference on the extent map, resulting in a use-after-free. Fix this by computing 'add_size' before dropping our extent map reference.

Published: 2024-08-17Modified: 2026-03-27
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-42316
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm/mglru: fix div-by-zero in vmpressure_calc_level() evict_folios() uses a second pass to reclaim folios that have gone through page writeback and become clean before it finishes the first pass, since folio_rotate_reclaimable() cannot handle those folios due to the isolation. The second pass tries to avoid potential double counting by deducting scan_control->nr_scanned. However, this can result in underflow of nr_scanned, under a condition where shrink_folio_list() does not increment nr_scanned, i.e., when folio_trylock() fails. The underflow can cause the divisor, i.e., scale=scanned+reclaimed in vmpressure_calc_level(), to become zero, resulting in the following crash: [exception RIP: vmpressure_work_fn+101] process_one_work at ffffffffa3313f2b Since scan_control->nr_scanned has no established semantics, the potential double counting has minimal risks. Therefore, fix the problem by not deducting scan_control->nr_scanned in evict_folios().

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42318
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: landlock: Don't lose track of restrictions on cred_transfer When a process' cred struct is replaced, this _almost_ always invokes the cred_prepare LSM hook; but in one special case (when KEYCTL_SESSION_TO_PARENT updates the parent's credentials), the cred_transfer LSM hook is used instead. Landlock only implements the cred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causes all information on Landlock restrictions to be lost. This basically means that a process with the ability to use the fork() and keyctl() syscalls can get rid of all Landlock restrictions on itself. Fix it by adding a cred_transfer hook that does the same thing as the existing cred_prepare hook. (Implemented by having hook_cred_prepare() call hook_cred_transfer() so that the two functions are less likely to accidentally diverge in the future.)

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42320
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error checks in dasd_copy_pair_store() dasd_add_busid() can return an error via ERR_PTR() if an allocation fails. However, two callsites in dasd_copy_pair_store() do not check the result, potentially resulting in a NULL pointer dereference. Fix this by checking the result with IS_ERR() and returning the error up the stack.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42321
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: flow_dissector: use DEBUG_NET_WARN_ON_ONCE The following splat is easy to reproduce upstream as well as in -stable kernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net") but this complementary fix has been also suggested by Willem de Bruijn and it can be easily backported to -stable kernel which consists in using DEBUG_NET_WARN_ON_ONCE instead to silence the following splat given __skb_get_hash() is used by the nftables tracing infrastructure to to identify packets in traces. [69133.561393] ------------[ cut here ]------------ [69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/ [...] [69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379 [69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0 [69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff ff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8 [69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246 [69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19 [69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418 [69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000 [69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400 [69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28 [69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0 [69133.562040] Call Trace: [69133.562044] [69133.562049] ? __warn+0x9f/0x1a0 [ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860 [...] [ 1211.841496] ? bpf_flow_dissect+0x160/0x160 [ 1211.841753] __skb_get_hash+0x97/0x280 [ 1211.841765] ? __skb_get_hash_symmetric+0x230/0x230 [ 1211.841776] ? mod_find+0xbf/0xe0 [ 1211.841786] ? get_stack_info_noinstr+0x12/0xe0 [ 1211.841798] ? bpf_ksym_find+0x56/0xe0 [ 1211.841807] ? __rcu_read_unlock+0x2a/0x70 [ 1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables] [ 1211.841895] ? nft_trace_notify+0x830/0x830 [nf_tables] [ 1211.841964] ? get_stack_info+0x2b/0x80 [ 1211.841975] ? nft_do_chain_arp+0x80/0x80 [nf_tables] [ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables]

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-42322
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipvs: properly dereference pe in ip_vs_add_service Use pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43817
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: missing check virtio Two missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again 1. After the skb_segment function the buffer may become non-linear (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere the __skb_linearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skb_headlen(skb)) becomes true, which causes WARN_ON_ONCE in skb_checksum_help. 2. The struct sk_buff and struct virtio_net_hdr members must be mathematically related. (gso_size) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) may be 0 if division is without remainder. offset+2 (4191) > skb_headlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Found by Linux Verification Center (linuxtesting.org) with Syzkaller

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43818
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: Adjust error handling in case of absent codec device acpi_get_first_physical_node() can return NULL in several cases (no such device, ACPI table error, reference count drop to 0, etc). Existing check just emit error message, but doesn't perform return. Then this NULL pointer is passed to devm_acpi_dev_add_driver_gpios() where it is dereferenced. Adjust this error handling by adding error code return. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43823
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs() If IORESOURCE_MEM is not provided in Device Tree due to any error, resource_list_first_type() will return NULL and pci_parse_request_of_pci_ranges() will just emit a warning. This will cause a NULL pointer dereference. Fix this bug by adding NULL return check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43828
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: fix infinite loop when replaying fast_commit When doing fast_commit replay an infinite loop may occur due to an uninitialized extent_status struct. ext4_ext_determine_insert_hole() does not detect the replay and calls ext4_es_find_extent_range(), which will return immediately without initializing the 'es' variable. Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039. This commit fixes this issue by unconditionally initializing the structure in function ext4_es_find_extent_range(). Thanks to Zhang Yi, for figuring out the real problem!

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43829
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/qxl: Add check for drm_cvt_mode Add check for the return value of drm_cvt_mode() and return the error if it fails in order to avoid NULL pointer dereference.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43830
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: leds: trigger: Unregister sysfs attributes before calling deactivate() Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback. Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data. Move the device_remove_groups() call to before deactivate() to close this race window. This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups().

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-43831
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Handle invalid decoder vsi Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is valid for future use.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43832
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: s390/uv: Don't call folio_wait_writeback() without a folio reference folio_wait_writeback() requires that no spinlocks are held and that a folio reference is held, as documented. After we dropped the PTL, the folio could get freed concurrently. So grab a temporary reference.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43833
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Fix NULL pointer dereference in adding ancillary links In v4l2_async_create_ancillary_links(), ancillary links are created for lens and flash sub-devices. These are sub-device to sub-device links and if the async notifier is related to a V4L2 device, the source sub-device of the ancillary link is NULL, leading to a NULL pointer dereference. Check the notifier's sd field is non-NULL in v4l2_async_create_ancillary_links(). [Sakari Ailus: Reword the subject and commit messages slightly.]

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43834
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xdp: fix invalid wait context of page_pool_destroy() If the driver uses a page pool, it creates a page pool with page_pool_create(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. page_pool_destroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is mem_allocator_disconnect(). This function internally acquires mutex_lock(). If the driver uses XDP, it registers a memory model with xdp_rxq_info_reg_mem_model(). The xdp_rxq_info_reg_mem_model() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2. To destroy a page pool, the driver should call both page_pool_destroy() and xdp_unreg_mem_model(). The xdp_unreg_mem_model() internally calls page_pool_destroy(). Only page_pool_destroy() decreases a reference count. If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we will face an invalid wait context warning. Because xdp_unreg_mem_model() calls page_pool_destroy() with rcu_read_lock(). The page_pool_destroy() internally acquires mutex_lock(). Splat looks like: ============================= [ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W ----------------------------- ethtool/1806 is trying to lock: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150 ? __wake_up_klogd.part.0+0x16/0xc0 ? __pfx_lock_acquire+0x10/0x10 ? dump_stack_lvl+0x91/0xc0 __mutex_lock+0x15c/0x1690 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_prb_read_valid+0x10/0x10 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_llist_add_batch+0x10/0x10 ? console_unlock+0x193/0x1b0 ? lockdep_hardirqs_on+0xbe/0x140 ? __pfx___mutex_lock+0x10/0x10 ? tick_nohz_tick_stopped+0x16/0x90 ? __irq_work_queue_local+0x1e5/0x330 ? irq_work_queue+0x39/0x50 ? __wake_up_klogd.part.0+0x79/0xc0 ? mem_allocator_disconnect+0x73/0x150 mem_allocator_disconnect+0x73/0x150 ? __pfx_mem_allocator_disconnect+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? rcu_is_watching+0x11/0xb0 page_pool_release+0x36e/0x6d0 page_pool_destroy+0xd7/0x440 xdp_unreg_mem_model+0x1a7/0x2a0 ? __pfx_xdp_unreg_mem_model+0x10/0x10 ? kfree+0x125/0x370 ? bnxt_free_ring.isra.0+0x2eb/0x500 ? bnxt_free_mem+0x5ac/0x2500 xdp_rxq_info_unreg+0x4a/0xd0 bnxt_free_mem+0x1356/0x2500 bnxt_close_nic+0xf0/0x3b0 ? __pfx_bnxt_close_nic+0x10/0x10 ? ethnl_parse_bit+0x2c6/0x6d0 ? __pfx___nla_validate_parse+0x10/0x10 ? __pfx_ethnl_parse_bit+0x10/0x10 bnxt_set_features+0x2a8/0x3e0 __netdev_update_features+0x4dc/0x1370 ? ethnl_parse_bitset+0x4ff/0x750 ? __pfx_ethnl_parse_bitset+0x10/0x10 ? __pfx___netdev_update_features+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? _raw_spin_unlock_irqrestore+0x42/0x70 ? __pm_runtime_resume+0x7d/0x110 ethnl_set_features+0x32d/0xa20 To fix this problem, it uses rhashtable_lookup_fast() instead of rhashtable_lookup() with rcu_read_lock(). Using xa without rcu_read_lock() here is safe. xa is freed by __xdp_mem_allocator_rcu_free() and this is called by call_rcu() of mem_xa_remove(). The mem_xa_remove() is called by page_pool_destroy() if a reference count reaches 0. The xa is already protected by the reference count mechanism well in the control plane. So removing rcu_read_lock() for page_pool_destroy() is safe.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43837
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT When loading a EXT program without specifying `attr->attach_prog_fd`, the `prog->aux->dst_prog` will be null. At this time, calling resolve_prog_type() anywhere will result in a null pointer dereference. Example stack trace: [ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 8.108262] Mem abort info: [ 8.108384] ESR = 0x0000000096000004 [ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits [ 8.108722] SET = 0, FnV = 0 [ 8.108827] EA = 0, S1PTW = 0 [ 8.108939] FSC = 0x04: level 0 translation fault [ 8.109102] Data abort info: [ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000 [ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000 [ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 8.112783] Modules linked in: [ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1 [ 8.113230] Hardware name: linux,dummy-virt (DT) [ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0 [ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8 [ 8.113798] sp : ffff80008283b9f0 [ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001 [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000 [ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000 [ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff [ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720 [ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 [ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4 [ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f [ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c [ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000 [ 8.114126] Call trace: [ 8.114159] may_access_direct_pkt_data+0x24/0xa0 [ 8.114202] bpf_check+0x3bc/0x28c0 [ 8.114214] bpf_prog_load+0x658/0xa58 [ 8.114227] __sys_bpf+0xc50/0x2250 [ 8.114240] __arm64_sys_bpf+0x28/0x40 [ 8.114254] invoke_syscall.constprop.0+0x54/0xf0 [ 8.114273] do_el0_svc+0x4c/0xd8 [ 8.114289] el0_svc+0x3c/0x140 [ 8.114305] el0t_64_sync_handler+0x134/0x150 [ 8.114331] el0t_64_sync+0x168/0x170 [ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403) [ 8.118672] ---[ end trace 0000000000000000 ]--- One way to fix it is by forcing `attach_prog_fd` non-empty when bpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type` API broken which use verifier log to probe prog type and will log nothing if we reject invalid EXT prog before bpf_check(). Another way is by adding null check in resolve_prog_type(). The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to prog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") which wanted to correct type resolution for BPF_PROG_TYPE_TRACING programs. Before that, the type resolution of BPF_PROG_TYPE_EXT prog actually follows the logic below: prog->aux->dst_prog ? prog->aux->dst_prog->type : prog->type; It implies that when EXT program is not yet attached to `dst_prog`, the prog type should be EXT itself. This code worked fine in the past. So just keep using it. Fix this by returning `prog->type` for BPF_PROG_TYPE_EXT if `dst_prog` is not present in resolve_prog_type().

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43839
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: bna: adjust 'name' buf size of bna_tcb and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace.

Published: 2024-08-17Modified: 2026-03-27
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-43841
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: avoid reporting connection success with wrong SSID When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found). The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning. Fixed it by checking the SSID (from user space) in the connection code.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
References
CVE-2024-43842
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() In rtw89_sta_info_get_iter() 'status->he_gi' is compared to array size. But then 'rate->he_gi' is used as array index instead of 'status->he_gi'. This can lead to go beyond array boundaries in case of 'rate->he_gi' is not equal to 'status->he_gi' and is bigger than array size. Looks like "copy-paste" mistake. Fix this mistake by replacing 'rate->he_gi' with 'status->he_gi'. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-43846
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: lib: objagg: Fix general protection fault The library supports aggregation of objects into other objects only if the parent object does not have a parent itself. That is, nesting is not supported. Aggregation happens in two cases: Without and with hints, where hints are a pre-computed recommendation on how to aggregate the provided objects. Nesting is not possible in the first case due to a check that prevents it, but in the second case there is no check because the assumption is that nesting cannot happen when creating objects based on hints. The violation of this assumption leads to various warnings and eventually to a general protection fault [1]. Before fixing the root cause, error out when nesting happens and warn. [1] general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80 [...] Call Trace: mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43849
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: protect locator_addr with the main mutex If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
References
CVE-2024-43850
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove The following warning is seen during bwmon_remove due to refcount imbalance, fix this by releasing the OPPs after use. Logs: WARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158 Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT) ... Call trace: _opp_table_kref_release+0x150/0x158 dev_pm_opp_remove_table+0x100/0x1b4 devm_pm_opp_of_table_release+0x10/0x1c devm_action_release+0x14/0x20 devres_release_all+0xa4/0x104 device_unbind_cleanup+0x18/0x60 device_release_driver_internal+0x1ec/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 bwmon_driver_exit+0x18/0x524 [icc_bwmon] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x34/0xdc el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 --[ end trace 0000000000000000 ]---

Published: 2024-08-17Modified: 2024-09-30
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43851
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: rename cpu_number1 to dummy_cpu_number The per cpu variable cpu_number1 is passed to xlnx_event_handler as argument "dev_id", but it is not used in this function. So drop the initialization of this variable and rename it to dummy_cpu_number. This patch is to fix the following call trace when the kernel option CONFIG_DEBUG_ATOMIC_SLEEP is enabled: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53 Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT) Call trace: dump_backtrace+0xd0/0xe0 show_stack+0x18/0x40 dump_stack_lvl+0x7c/0xa0 dump_stack+0x18/0x34 __might_resched+0x10c/0x140 __might_sleep+0x4c/0xa0 __kmem_cache_alloc_node+0xf4/0x168 kmalloc_trace+0x28/0x38 __request_percpu_irq+0x74/0x138 xlnx_event_manager_probe+0xf8/0x298 platform_probe+0x68/0xd8

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43853
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Prevent UAF in proc_cpuset_show() An UAF can happen when /proc/cpuset is read as reported in [1]. This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc//cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly. The race that cause this bug can be shown as below: (umount) | (cat /proc//cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); cgroup_destroy_root | mutex_lock(&cgroup_mutex); rebind_subsystems | cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..); When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp. The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgroup_root should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed. Fix this problem by using rcu_read_lock in proc_cpuset_show(). As cgroup_root is kfree_rcu after commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe"), css->cgroup won't be freed during the critical section. To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to replace task_get_css with task_css. [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43854
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43855
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: md: fix deadlock between mddev_suspend and flush bio Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue. T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3. T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . md_handle_request . . active_io + 1 . . md_flush_request . . wait !mddev->flush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_flush_data is already running (T1) . md_handle_request wait resume The root issue is non-atomic inc/dec of active_io during flush process. active_io is dec before md_submit_flush_data is queued, and inc soon after md_submit_flush_data() run. md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1 If active_io is dec after md_handle_request() instead of within submit_flushes(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed. Additionally, the only difference between fixing the issue and before is that there is no return error handling of make_request(). But after previous patch cleaned md_write_start(), make_requst() only return error in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be called in md_submit_flush_data(). To prevent future modifications from introducing issues, add WARN_ON to ensure make_request() no error is returned in this context.

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43856
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43858
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix array-index-out-of-bounds in diFree

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-43859
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate preallocated blocks in f2fs_file_open() chenyuwen reports a f2fs bug as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011 fscrypt_set_bio_crypt_ctx+0x78/0x1e8 f2fs_grab_read_bio+0x78/0x208 f2fs_submit_page_read+0x44/0x154 f2fs_get_read_data_page+0x288/0x5f4 f2fs_get_lock_data_page+0x60/0x190 truncate_partial_data_page+0x108/0x4fc f2fs_do_truncate_blocks+0x344/0x5f0 f2fs_truncate_blocks+0x6c/0x134 f2fs_truncate+0xd8/0x200 f2fs_iget+0x20c/0x5ac do_garbage_collect+0x5d0/0xf6c f2fs_gc+0x22c/0x6a4 f2fs_disable_checkpoint+0xc8/0x310 f2fs_fill_super+0x14bc/0x1764 mount_bdev+0x1b4/0x21c f2fs_mount+0x20/0x30 legacy_get_tree+0x50/0xbc vfs_get_tree+0x5c/0x1b0 do_new_mount+0x298/0x4cc path_mount+0x33c/0x5fc __arm64_sys_mount+0xcc/0x15c invoke_syscall+0x60/0x150 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0xa0 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec It is because inode.i_crypt_info is not initialized during below path: - mount - f2fs_fill_super - f2fs_disable_checkpoint - f2fs_gc - f2fs_iget - f2fs_truncate So, let's relocate truncation of preallocated blocks to f2fs_file_open(), after fscrypt_file_open().

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43860
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Skip over memory region when node value is NULL In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts number of phandles. But phandles may be empty. So of_parse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. [Fixed title to fit within the prescribed 70-75 charcters]

Published: 2024-08-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43861
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: fix memory leak for not ip packets Free the unused skb when not ip packets arrive.

Published: 2024-08-20Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43863
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43866
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43867
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: prime: fix refcount underflow Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow. Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually. (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43869
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exec and file release The perf pending task work is never waited upon the matching event release. In the case of a child event, released via free_event() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger: schedule() prepare_task_switch() =======> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= perf_event_task_sched_out() event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) finish_lock_switch() =======> perf_pending_irq() //do nothing, rely on pending task work <======= begin_new_exec() perf_event_exit_task() perf_event_exit_event() // If is child event free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // event is leaked Similar scenarios can also happen with perf_event_remove_on_exec() or simply against concurrent perf_event_release(). Fix this with synchonizing against the possibly remaining pending task work while freeing the event, just like is done with remaining pending IRQ work. This means that the pending task callback neither need nor should hold a reference to the event, preventing it from ever beeing freed.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43870
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exit When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via task_work. However failures while adding an event's callback to the task_work engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount addition such as in the following scenario: TASK A ----- do_exit() exit_task_work(tsk); perf_event_overflow() event->pending_sigtrap = pending_id; irq_work_queue(&event->pending_irq); =========> PREEMPTION: TASK A -> TASK B event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) // FAILS: task work has exited task_work_add(&event->pending_task) [...] perf_pending_irq() // early return: event->oncpu = -1 [...] =========> TASK B -> TASK A perf_event_exit_task(tsk) perf_event_exit_event() free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // leak event due to unexpected refcount == 2 As a result the event is never released while the task exits. Fix this with appropriate task_work_add()'s error handling.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43871
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu().

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43873
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-43875
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Clean up error handling in vpci_scan_bus() Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of failure.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43876
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: PCI: rcar: Demote WARN() to dev_warn_ratelimited() in rcar_pcie_wakeup() Avoid large backtrace, it is sufficient to warn the user that there has been a link problem. Either the link has failed and the system is in need of maintenance, or the link continues to work and user has been informed. The message from the warning can be looked up in the sources. This makes an actual link issue less verbose. First of all, this controller has a limitation in that the controller driver has to assist the hardware with transition to L1 link state by writing L1IATN to PMCTRL register, the L1 and L0 link state switching is not fully automatic on this controller. In case of an ASMedia ASM1062 PCIe SATA controller which does not support ASPM, on entry to suspend or during platform pm_test, the SATA controller enters D3hot state and the link enters L1 state. If the SATA controller wakes up before rcar_pcie_wakeup() was called and returns to D0, the link returns to L0 before the controller driver even started its transition to L1 link state. At this point, the SATA controller did send an PM_ENTER_L1 DLLP to the PCIe controller and the PCIe controller received it, and the PCIe controller did set PMSR PMEL1RX bit. Once rcar_pcie_wakeup() is called, if the link is already back in L0 state and PMEL1RX bit is set, the controller driver has no way to determine if it should perform the link transition to L1 state, or treat the link as if it is in L0 state. Currently the driver attempts to perform the transition to L1 link state unconditionally, which in this specific case fails with a PMSR L1FAEG poll timeout, however the link still works as it is already back in L0 state. Reduce this warning verbosity. In case the link is really broken, the rcar_pcie_config_access() would fail, otherwise it will succeed and any system with this controller and ASM1062 can suspend without generating a backtrace.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43877
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: media: pci: ivtv: Add check for DMA map result In case DMA fails, 'dma->SG_length' is 0. This value is later used to access 'dma->SGarray[dma->SG_length - 1]', which will cause out of bounds access. Add check to return early on invalid value. Adjust warnings accordingly. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-43879
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he() Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning: kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43880
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_erp: Fix object nesting warning ACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM (A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former can contain more ACLs (i.e., tc filters), but the number of masks in each region (i.e., tc chain) is limited. In order to mitigate the effects of the above limitation, the device allows filters to share a single mask if their masks only differ in up to 8 consecutive bits. For example, dst_ip/25 can be represented using dst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on the number of masks being used (and therefore does not support mask aggregation), but can contain a limited number of filters. The driver uses the "objagg" library to perform the mask aggregation by passing it objects that consist of the filter's mask and whether the filter is to be inserted into the A-TCAM or the C-TCAM since filters in different TCAMs cannot share a mask. The set of created objects is dependent on the insertion order of the filters and is not necessarily optimal. Therefore, the driver will periodically ask the library to compute a more optimal set ("hints") by looking at all the existing objects. When the library asks the driver whether two objects can be aggregated the driver only compares the provided masks and ignores the A-TCAM / C-TCAM indication. This is the right thing to do since the goal is to move as many filters as possible to the A-TCAM. The driver also forbids two identical masks from being aggregated since this can only happen if one was intentionally put in the C-TCAM to avoid a conflict in the A-TCAM. The above can result in the following set of hints: H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + delta H3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + delta After getting the hints from the library the driver will start migrating filters from one region to another while consulting the computed hints and instructing the device to perform a lookup in both regions during the transition. Assuming a filter with mask X is being migrated into the A-TCAM in the new region, the hints lookup will return H1. Since H2 is the parent of H1, the library will try to find the object associated with it and create it if necessary in which case another hints lookup (recursive) will be performed. This hints lookup for {mask Y, A-TCAM} will either return H2 or H3 since the driver passes the library an object comparison function that ignores the A-TCAM / C-TCAM indication. This can eventually lead to nested objects which are not supported by the library [1]. Fix by removing the object comparison function from both the driver and the library as the driver was the only user. That way the lookup will only return exact matches. I do not have a reliable reproducer that can reproduce the issue in a timely manner, but before the fix the issue would reproduce in several minutes and with the fix it does not reproduce in over an hour. Note that the current usefulness of the hints is limited because they include the C-TCAM indication and represent aggregation that cannot actually happen. This will be addressed in net-next. [1] WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0 Modules linked in: CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42 Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0 [...] Call Trace: __objagg_obj_get+0x2bb/0x580 objagg_obj_get+0xe/0x80 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0 mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43882
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal.

Published: 2024-08-21Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-43883
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: usb: vhci-hcd: Do not drop references before new references are gained At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.

Published: 2024-08-23Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-43889
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: padata: Fix possible divide-by-0 panic in padata_mt_helper() We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time. [ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: events_unbound padata_mt_helper [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] [ 10.018004] ? padata_mt_helper+0x39/0xb0 [ 10.018084] process_one_work+0x174/0x330 [ 10.018093] worker_thread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] ret_from_fork+0x31/0x50 [ 10.018138] ret_from_fork_asm+0x1a/0x30 [ 10.018147] Looking at the padata_mt_helper() function, the only way a divide-by-0 panic can happen is when ps->chunk_size is 0. The way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed-in padata_mt_job structure is 0. Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43890
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tracing: Fix overflow in get_free_elt() "tracing_map->next_elt" in get_free_elt() is at risk of overflowing. Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (`max_elts`) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using `__tracing_map_insert()`, it will cause an infinite loop with preemption disabled, leading to a CPU hang problem. Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt".

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43892
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43893
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: serial: core: check uartclk for zero to avoid divide by zero Calling ioctl TIOCSSERIAL with an invalid baud_base can result in uartclk being zero, which will result in a divide by zero error in uart_get_divisor(). The check for uartclk being zero in uart_set_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set. Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580) Call Trace: serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576 drivers/tty/serial/8250/8250_port.c:2589) serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502 drivers/tty/serial/8250/8250_port.c:2741) serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862) uart_change_line_settings (./include/linux/spinlock.h:376 ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222) uart_port_startup (drivers/tty/serial/serial_core.c:342) uart_startup (drivers/tty/serial/serial_core.c:368) uart_set_info (drivers/tty/serial/serial_core.c:1034) uart_set_info_user (drivers/tty/serial/serial_core.c:1059) tty_set_serial (drivers/tty/tty_io.c:2637) tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791) __x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Rule: add

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43894
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/client: fix null pointer dereference in drm_client_modeset_probe In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43897
MEDIUM5.5

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.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43900
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: media: xc2028: avoid use-after-free in load_firmware_cb() syzkaller reported use-after-free in load_firmware_cb() [1]. The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free. The process is as follows: task-6504 worker_thread tuner_probe <= alloc dvb_frontend [2] ... request_firmware_nowait <= create a worker ... tuner_remove <= free dvb_frontend ... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freed To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is null, report a warning and just return. [1]: ================================================================== BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504 Call trace: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 process_one_work+0x770/0x1824 worker_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20 Allocated by task 6504: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 really_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 device_initial_probe+0x20/0x30 bus_probe_device+0x184/0x200 device_add+0x924/0x12c0 device_register+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770 Freed by task 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 i2c_device_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc device_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770 The buggy address belongs to the object at ffff8000d7ca2000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 776 bytes inside of 2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800) The buggy address belongs to the page: page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0 flags: 0x7ff800000000100(slab) raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-43902
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null checker before passing variables Checks null pointer before passing variables to functions. This fixes 3 NULL_RETURNS issues reported by Coverity.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43905
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr Check return value and conduct null pointer handling to avoid null pointer dereference.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43906
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/admgpu: fix dereferencing null pointer context When user space sets an invalid ta type, the pointer context will be empty. So it need to check the pointer context before using it

Published: 2024-08-26Modified: 2024-08-27
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43907
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules Check the pointer value to fix potential null pointer dereference

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43908
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix the null pointer dereference to ras_manager Check ras_manager before using it

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43909
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix the null pointer dereference for smu7 optimize the code to avoid pass a null pointer (hwmgr->backend) to function smu7_update_edc_leakage_table.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43912
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: disallow setting special AP channel widths Setting the AP channel width is meant for use with the normal 20/40/... MHz channel width progression, and switching around in S1G or narrow channels isn't supported. Disallow that.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-43914
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: md/raid5: avoid BUG_ON() while continue reshape after reassembling Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test: kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Call Trace: raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail. Fix this panic the easy way first, by converting the BUG_ON() to WARN_ON(), and stop the reshape if checkings fail. Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44931
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: gpio: prevent potential speculation leaks in gpio_device_get_desc() Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpio_ioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpio_device_get_desc(). This change ensures that the offset is sanitized by using array_index_nospec() to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-44934
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: wait for previous gc cycles when removing port syzbot hit a use-after-free[1] which is caused because the bridge doesn't make sure that all previous garbage has been collected when removing a port. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still running Make sure all previous gc cycles have finished by using flush_work before freeing the port. [1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699 CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44935
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sctp: Fix null-ptr-deref in reuseport_add_sock(). syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in reuseport_add_sock(). [0] The repro first creates a listener with SO_REUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener. The second listen() calls reuseport_add_sock() with the first listener as sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently, but the close() does clear it by reuseport_detach_sock(). The problem is SCTP does not properly synchronise reuseport_alloc(), reuseport_add_sock(), and reuseport_detach_sock(). The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must provide synchronisation for sockets that are classified into the same reuseport group. Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead. 1. Two sockets call listen() concurrently 2. No socket in the same group found in sctp_ep_hashtable[] 3. Two sockets call reuseport_alloc() and form two reuseport groups 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives incoming packets Also, the reported null-ptr-deref could occur. TCP/UDP guarantees that would not happen by holding the hash bucket lock. Let's apply the locking strategy to __sctp_hash_endpoint() and __sctp_unhash_endpoint(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350 Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __sctp_hash_endpoint net/sctp/input.c:762 [inline] sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] __se_sys_listen net/socket.c:1900 [inline] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c R13: ---truncated---

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44938
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix shift-out-of-bounds in dbDiscardAG When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative. This patch fixes the issue by exiting the loop directly when negative shift is found.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44939
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: jfs: fix null ptr deref in dtInsertEntry [syzbot reported] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713 ... [Analyze] In dtInsertEntry(), when the pointer h has the same value as p, after writing name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the previously true judgment "p->header.flag & BT-LEAF" to change to no after writing the name operation, this leads to entering an incorrect branch and accessing the uninitialized object ih when judging this condition for the second time. [Fix] After got the page, check freelist first, if freelist == 0 then exit dtInsert() and return -EINVAL.

Published: 2024-08-26Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44940
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: fou: remove warn in gue_gro_receive on unsupported protocol Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler. Such a packet is easily constructed. Syzbot generates them and sets off this warning. Remove the warning as it is expected and not actionable. The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks").

Published: 2024-08-26Modified: 2026-04-01
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44942
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback. Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing.

Published: 2024-08-26Modified: 2024-08-27
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44944
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use helper function to calculate expect ID Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.

Published: 2024-08-30Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44946
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: kcm: Serialise kcm_sendmsg() for the same socket. syzkaller reported UAF in kcm_release(). [0] The scenario is 1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb. 2. Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory() 3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue 4. Thread A faces an error and finally frees skb that is already in the write queue 5. kcm_release() does double-free the skb in the write queue When a thread is building a MSG_MORE skb, another thread must not touch it. Let's add a per-sk mutex and serialise kcm_sendmsg(). [0]: BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline] BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167 CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated---

Published: 2024-08-31Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44947
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fuse: Initialize beyond-EOF page contents before setting uptodate fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents). So fuse_notify_store() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate. The current code can leave beyond-EOF page contents uninitialized, which makes these uninitialized page contents visible to userspace via mmap(). This is an information leak, but only affects systems which do not enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the corresponding kernel command line parameter).

Published: 2024-09-02Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-44948
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/mtrr: Check if fixed MTRRs exist before saving them MTRRs have an obsolete fixed variant for fine grained caching control of the 640K-1MB region that uses separate MSRs. This fixed variant has a separate capability bit in the MTRR capability MSR. So far all x86 CPUs which support MTRR have this separate bit set, so it went unnoticed that mtrr_save_state() does not check the capability bit before accessing the fixed MTRR MSRs. Though on a CPU that does not support the fixed MTRR capability this results in a #GP. The #GP itself is harmless because the RDMSR fault is handled gracefully, but results in a WARN_ON(). Add the missing capability check to prevent this.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44949
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: parisc: fix a possible DMA corruption ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44954
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Fix racy access to midibuf There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44957
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Switch from mutex to spinlock for irqfds irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock. Fix it by switching over to a spin lock.

Published: 2024-09-04Modified: 2024-09-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44958
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sched/smt: Fix unbalance sched_smt_present dec/inc I got the following warn report while doing stress test: jump label: negative count! WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Call Trace: __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(), the cpu offline failed, but sched_smt_present is decremented before calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so fix it by incrementing sched_smt_present in the error path.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44960
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: core: Check for unset descriptor Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case. This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found. No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44961
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Forward soft recovery errors to userspace As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ (cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01)

Published: 2024-09-04Modified: 2024-10-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44962
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming. panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 __el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,c0000000,40028143,1000721b Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

Published: 2024-09-04Modified: 2024-10-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44965
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix pti_clone_pgtable() alignment assumption Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then #DF from the stack guard. It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386. These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text? Use the correct increment form for addr to avoid alignment assumptions.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44966
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix corruption when not offsetting data start Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment. Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44967
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/mgag200: Bind I2C lifetime to DRM device Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc. Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44969
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Prevent release of buffer in I/O When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time. Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44970
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44971
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register() bcm_sf2_mdio_register() calls of_phy_find_device() and then phy_device_remove() in a loop to remove existing PHY devices. of_phy_find_device() eventually calls bus_find_device(), which calls get_device() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak. This commit adds the missing phy_device_free() call to decrement the refcount via put_device() to balance the refcount.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44974
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: avoid possible UaF when selecting endp select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free. A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with.

Published: 2024-09-04Modified: 2026-04-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44977
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Validate TA binary size Add TA binary size validation to avoid OOB write. (cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442)

Published: 2024-09-04Modified: 2026-04-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44982
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails If the dpu_format_populate_layout() fails, then FB is prepared, but not cleaned up. This ends up leaking the pin_count on the GEM object and causes a splat during DRM file closure: msm_obj->pin_count WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc [...] Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 irq event stamp: 129818 hardirqs last enabled at (129817): [] console_unlock+0x118/0x124 hardirqs last disabled at (129818): [] el1_dbg+0x24/0x8c softirqs last enabled at (129808): [] handle_softirqs+0x4c8/0x4e8 softirqs last disabled at (129785): [] __do_softirq+0x14/0x20 Patchwork: https://patchwork.freedesktop.org/patch/600714/

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44983
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate vlan header Ensure there is sufficient room to access the protocol field of the VLAN header, validate it once before the flowtable lookup. ===================================================== BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5440 [inline]

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-44985
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UAF in ip6_xmit() If skb_expand_head() returns NULL, skb has been freed and the associated dst/idev could also have been freed. We must use rcu_read_lock() to prevent a possible UAF.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44986
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in ip6_finish_output2() If skb_expand_head() returns NULL, skb has been freed and associated dst/idev could also have been freed. We need to hold rcu_read_lock() to make sure the dst and associated idev are alive.

Published: 2024-09-04Modified: 2026-04-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44987
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent UAF in ip6_send_skb() syzbot reported an UAF in ip6_send_skb() [1] After ip6_local_out() has returned, we no longer can safely dereference rt, unless we hold rcu_read_lock(). A similar issue has been fixed in commit a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()") Another potential issue in ip6_finish_output2() is handled in a separate patch. [1] BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530 CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f936bf79e79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79 RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 Allocated by task 6530: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [inline] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 45: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kmem_cache_free+0x145/0x350 mm/slub.c:4548 dst_destroy+0x2ac/0x460 net/core/dst.c:124 rcu_do_batch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree. ---truncated---

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44988
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix out-of-bound access If an ATU violation was caused by a CPU Load operation, the SPID could be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44989
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bonding: fix xfrm real_dev null pointer dereference We shouldn't set real_dev to NULL because packets can be in transit and xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume real_dev is set. Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: kernel: ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ip_push_pending_frames+0x56/0x80

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44990
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bonding: fix null pointer deref in bond_ipsec_offload_ok We must check if there is an active slave before dereferencing the pointer.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44991
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tcp: prevent concurrent execution of tcp_sk_exit_batch Its possible that two threads call tcp_sk_exit_batch() concurrently, once from the cleanup_net workqueue, once from a task that failed to clone a new netns. In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns. tcp_sk_exit_batch() calls tcp_twsk_purge(). Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"), this function picks up twsk in any dying netns, not just the one passed in via exit_batch list. This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns. This allows the netns exit worker to proceed to call WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount)); without the expected 1 -> 0 transition, which then splats. At same time, error unwind path that is also running inet_twsk_purge() will splat as well: WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ... refcount_dec include/linux/refcount.h:351 [inline] inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 setup_net+0x714/0xb40 net/core/net_namespace.c:375 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 ... because refcount_dec() of tw_refcount unexpectedly dropped to 0. This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check. Add a mutex to force strict ordering: the task that calls tcp_twsk_purge() blocks other task from doing final _dec_and_test before mutex-owner has removed all tw sockets of dying netns.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44995
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix a deadlock problem when config TC during resetting When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable() In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-44998
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: atm: idt77252: prevent use after free in dequeue_rx() We can't dereference "skb" after calling vcc->push() because the skb is released.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-44999
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: gtp: pull network headers in gtp_dev_xmit() syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1] We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them. Use pskb_inet_may_pull() to fix this issue. [1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-45000
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fs/netfs/fscache_cookie: add missing "n_accesses" check This fixes a NULL pointer dereference bug due to a data race which looks like this: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 Workqueue: events_unbound netfs_rreq_write_to_cache_work RIP: 0010:cachefiles_prepare_write+0x30/0xa0 Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Call Trace: ? __die+0x1f/0x70 ? page_fault_oops+0x15d/0x440 ? search_module_extables+0xe/0x40 ? fixup_exception+0x22/0x2f0 ? exc_page_fault+0x5f/0x100 ? asm_exc_page_fault+0x22/0x30 ? cachefiles_prepare_write+0x30/0xa0 netfs_rreq_write_to_cache_work+0x135/0x2e0 process_one_work+0x137/0x2c0 worker_thread+0x2e9/0x400 ? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Modules linked in: CR2: 0000000000000008 ---[ end trace 0000000000000000 ]--- This happened because fscache_cookie_state_machine() was slow and was still running while another process invoked fscache_unuse_cookie(); this led to a fscache_cookie_lru_do_one() call, setting the FSCACHE_COOKIE_DO_LRU_DISCARD flag, which was picked up by fscache_cookie_state_machine(), withdrawing the cookie via cachefiles_withdraw_cookie(), clearing cookie->cache_priv. At the same time, yet another process invoked cachefiles_prepare_write(), which found a NULL pointer in this code line: struct cachefiles_object *object = cachefiles_cres_object(cres); The next line crashes, obviously: struct cachefiles_cache *cache = object->volume->cache; During cachefiles_prepare_write(), the "n_accesses" counter is non-zero (via fscache_begin_operation()). The cookie must not be withdrawn until it drops to zero. The counter is checked by fscache_cookie_state_machine() before switching to FSCACHE_COOKIE_STATE_RELINQUISHING and FSCACHE_COOKIE_STATE_WITHDRAWING (in "case FSCACHE_COOKIE_STATE_FAILED"), but not for FSCACHE_COOKIE_STATE_LRU_DISCARDING ("case FSCACHE_COOKIE_STATE_ACTIVE"). This patch adds the missing check. With a non-zero access counter, the function returns and the next fscache_end_cookie_access() call will queue another fscache_cookie_state_machine() call to handle the still-pending FSCACHE_COOKIE_DO_LRU_DISCARD.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45002
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: rtla/osnoise: Prevent NULL dereference in error handling If the "tool->data" allocation fails then there is no need to call osnoise_free_top() and, in fact, doing so will lead to a NULL dereference.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45003
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ↓ ubifs_jnl_write_inode ABBA deadlock ←-----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated---

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45006
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference. Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint(). On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45007
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Don't destroy workqueue from work item running on it Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45008
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Input: MT - limit max slots syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE). Since nobody knows possible max slots, this patch chose 1024.

Published: 2024-09-04Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45009
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR. A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45010
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only mark 'subflow' endp as available Adding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... before decrementing the local_addr_used counter helped to find a bug when running the "remove single address" subtest from the mptcp_join.sh selftests. Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed. Now, the counter is decremented, only if the ID is being used outside of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and if the ID is not 0 -- local_addr_used is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45011
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Check USB endpoints when probing device Ensure, as the driver probes the device, that all endpoints that the driver may attempt to access exist and are of the correct type. All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at address 1. This is verified in xillyusb_setup_base_eps(). On top of that, a XillyUSB device may have additional Bulk OUT endpoints. The information about these endpoints' addresses is deduced from a data structure (the IDT) that the driver fetches from the device while probing it. These endpoints are checked in setup_channels(). A XillyUSB device never has more than one IN endpoint, as all data towards the host is multiplexed in this single Bulk IN endpoint. This is why setup_channels() only checks OUT endpoints.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45015
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable() For cases where the crtc's connectors_changed was set without enable/active getting toggled , there is an atomic_enable() call followed by an atomic_disable() but without an atomic_mode_set(). This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in the atomic_enable() as the dpu_encoder's connector was cleared in the atomic_disable() but not re-assigned as there was no atomic_mode_set() call. Fix the NULL ptr access by moving the assignment for atomic_enable() and also use drm_atomic_get_new_connector_for_encoder() to get the connector from the atomic_state. Patchwork: https://patchwork.freedesktop.org/patch/606729/

Published: 2024-09-11Modified: 2024-09-13
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45016
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netem: fix return value if duplicate enqueue fails There is a bug in netem_enqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free. This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR. There are two ways for the bug happen: - If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped. - If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped. In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc. The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45018
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: initialise extack before use Fix missing initialisation of extack in flow offload.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45019
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Take state lock during tx timeout reporter mlx5e_safe_reopen_channels() requires the state lock taken. The referenced changed in the Fixes tag removed the lock to fix another issue. This patch adds it back but at a later point (when calling mlx5e_safe_reopen_channels()) to avoid the deadlock referenced in the Fixes tag.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45021
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: memcg_write_event_control(): fix a user-triggerable oops we are *not* guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane).

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45025
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45026
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error recovery leading to data corruption on ESE devices Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-45028
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_test: Fix NULL dereference on allocation failure If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-45029
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: Do not mark ACPI devices as irq safe On ACPI machines, the tegra i2c module encounters an issue due to a mutex being called inside a spinlock. This leads to the following bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 ... Call trace: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xfer The problem arises because during __pm_runtime_resume(), the spinlock &dev->power.lock is acquired before rpm_resume() is called. Later, rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on mutexes, triggering the error. To address this issue, devices on ACPI are now marked as not IRQ-safe, considering the dependency of acpi_subsys_runtime_resume() on mutexes.

Published: 2024-09-11Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46673
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46674
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: st: fix probed platform device ref count on probe error path The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46675
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Prevent USB core invalid event buffer address access This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address. To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46676
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Add poll mod list filling check In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero. Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Add poll mod list filling check. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46677
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: gtp: fix a potential NULL pointer dereference When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case. Fix it by returning an error pointer with the error code carried from sockfd_lookup(). (I found this bug during code inspection.)

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46678
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bonding: change ipsec_lock from spin lock to mutex In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave. [ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? usleep_range_state+0x90/0x90 [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core] [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core] [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core] [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding] [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding] [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53 As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved.

Published: 2024-09-13Modified: 2024-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46679
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: ethtool: check device is present when getting link settings A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5, state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10). This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show"). There are many other callers of __ethtool_get_link_ksettings() which don't have a device presence check. Move this check into ethtool to protect all callers.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46685
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix potential NULL dereference in pcs_get_function() pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function(). Found by code review.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46686
MEDIUM5.5

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.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46689
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46694
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. (cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3)

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46695
MEDIUM4.4

In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 4.4
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N
References
CVE-2024-46702
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Mark XDomain as unplugged when router is removed I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock. However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46707
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2. We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?). The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46711
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix ID 0 endp usage after multiple re-creations 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46713
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch.

Published: 2024-09-13Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46714
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip wbscl_set_scaler_filter if filter is null Callers can pass null in filter (i.e. from returned from the function wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is not the case. This fixes 4 NULL_RETURNS issues reported by Coverity.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46715
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]---

Published: 2024-09-18Modified: 2026-04-18
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46716
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor Remove list_del call in msgdma_chan_desc_cleanup, this should be the role of msgdma_free_descriptor. In consequence replace list_add_tail with list_move_tail in msgdma_free_descriptor. This fixes the path: msgdma_free_chan_resources -> msgdma_free_descriptors -> msgdma_free_desc_list -> msgdma_free_descriptor which does not correctly free the descriptors as first nodes were not removed from the list.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46717
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix incorrect page release Under the following conditions: 1) No skb created yet 2) header_size == 0 (no SHAMPO header) 3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the last page fragment of a SHAMPO header page) a new skb is formed with a page that is NOT a SHAMPO header page (it is a regular data page). Further down in the same function (mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page from header_index is released. This is wrong and it leads to SHAMPO header pages being released more than once.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46719
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix null pointer dereference in trace ucsi_register_altmode checks IS_ERR for the alt pointer and treats NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled, ucsi_register_displayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typec_port_register_altmode to register DisplayPort alternate mode as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46720
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix dereference after null check check the pointer hive before use.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46721
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: apparmor: fix possible NULL pointer dereference profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made from __create_missing_ancestors(..) and 'ent->old' is NULL in aa_replace_profiles(..). In that case, it must return an error code and the code, -ENOENT represents its state that the path of its parent is not existed yet. BUG: kernel NULL pointer dereference, address: 0000000000000030 PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:aafs_create.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0 Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7be9f211c574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574 RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004 RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80 R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas CR2: 0000000000000030 ---[ end trace 0000000000000000 ]--- RIP: 0010:aafs_create.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000 ---truncated---

Published: 2024-09-18Modified: 2026-01-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46722
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix mc_data out-of-bounds read warning Clear warning that read mc_data[i-1] may out-of-bounds.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-46723
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix ucode out-of-bounds read warning Clear warning that read ucode[] may out-of-bounds.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-46724
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number Check the fb_channel_number range to avoid the array out-of-bounds read error

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-46725
HIGH7.8

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

Published: 2024-09-18Modified: 2026-04-21
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46726
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Ensure index calculation will not overflow [WHY & HOW] Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will never overflow and exceess array size. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46728
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check index for aux_rd_interval before using aux_rd_interval has size of 7 and should be checked. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.

Published: 2024-09-18Modified: 2024-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46731
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix the Out-of-bounds read warning using index i - 1U may beyond element index for mc_data[] when i = 0.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-46732
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Assign linear_pitch_alignment even for VM [Description] Assign linear_pitch_alignment so we don't cause a divide by 0 error in VM environments

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46735
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ublk_drv: fix NULL pointer dereference in ublk_ctrl_start_recovery() When two UBLK_CMD_START_USER_RECOVERY commands are submitted, the first one sets 'ubq->ubq_daemon' to NULL, and the second one triggers WARN in ublk_queue_reinit() and subsequently a NULL pointer dereference issue. Fix it by adding the check in ublk_ctrl_start_recovery() and return immediately in case of zero 'ub->nr_queues_ready'. BUG: kernel NULL pointer dereference, address: 0000000000000028 RIP: 0010:ublk_ctrl_start_recovery.constprop.0+0x82/0x180 Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x75/0x170 ? exc_page_fault+0x64/0x140 ? asm_exc_page_fault+0x22/0x30 ? ublk_ctrl_start_recovery.constprop.0+0x82/0x180 ublk_ctrl_uring_cmd+0x4f7/0x6c0 ? pick_next_task_idle+0x26/0x40 io_uring_cmd+0x9a/0x1b0 io_issue_sqe+0x193/0x3f0 io_wq_submit_work+0x9b/0x390 io_worker_handle_work+0x165/0x360 io_wq_worker+0xcb/0x2f0 ? finish_task_switch.isra.0+0x203/0x290 ? finish_task_switch.isra.0+0x203/0x290 ? __pfx_io_wq_worker+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_io_wq_worker+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46737
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix kernel crash if commands allocation fails If the commands allocation fails in nvmet_tcp_alloc_cmds() the kernel crashes in nvmet_tcp_release_queue_work() because of a NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Fix the bug by setting queue->nr_cmds to zero in case nvmet_tcp_alloc_cmd() fails.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46738
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix use-after-free when removing resource in vmci_resource_remove() When removing a resource from vmci_resource_table in vmci_resource_remove(), the search is performed using the resource handle by comparing context and resource fields. It is possible though to create two resources with different types but same handle (same context and resource fields). When trying to remove one of the resources, vmci_resource_remove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmci_datagram_destroy_handle(). vmci_resource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability. BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0 This change ensures the type is also checked when removing the resource from vmci_resource_table in vmci_resource_remove().

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46739
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind For primary VM Bus channels, primary_channel pointer is always NULL. This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary channels only. Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary channel.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46740
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF caused by offsets overwrite Binder objects are processed and copied individually into the target buffer during transactions. Any raw data in-between these objects is copied as well. However, this raw data copy lacks an out-of-bounds check. If the raw data exceeds the data section size then the copy overwrites the offsets section. This eventually triggers an error that attempts to unwind the processed objects. However, at this point the offsets used to index these objects are now corrupted. Unwinding with corrupted offsets can result in decrements of arbitrary nodes and lead to their premature release. Other users of such nodes are left with a dangling pointer triggering a use-after-free. This issue is made evident by the following KASAN report (trimmed): ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c Write of size 4 at addr ffff47fc91598f04 by task binder-util/743 CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1 Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x19c binder_free_buf+0x128/0x434 binder_thread_write+0x8a4/0x3260 binder_ioctl+0x18f0/0x258c [...] Allocated by task 743: __kmalloc_cache_noprof+0x110/0x270 binder_new_node+0x50/0x700 binder_transaction+0x413c/0x6da8 binder_thread_write+0x978/0x3260 binder_ioctl+0x18f0/0x258c [...] Freed by task 745: kfree+0xbc/0x208 binder_thread_read+0x1c5c/0x37d4 binder_ioctl+0x16d8/0x258c [...] ================================================================== To avoid this issue, let's check that the raw data copy is within the boundaries of the data section.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46742
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open() null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE) and parse_lease_state() return NULL. Fix this by check if 'lease_ctx_info' is NULL. Additionally, remove the redundant parentheses in parse_durable_handle_context().

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46743
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: of/irq: Prevent device address out-of-bounds read in interrupt map walk When of_irq_parse_raw() is invoked with a device address smaller than the interrupt parent node (from #address-cells property), KASAN detects the following out-of-bounds read when populating the initial match table (dyndbg="func of_irq_parse_* +p"): OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764 CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dump_backtrace+0xdc/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0x6c/0x84 print_report+0x150/0x448 kasan_report+0x98/0x140 __asan_load4+0x78/0xa0 of_irq_parse_raw+0x2b8/0x8d0 of_irq_parse_one+0x24c/0x270 parse_interrupts+0xc0/0x120 of_fwnode_add_links+0x100/0x2d0 fw_devlink_parse_fwtree+0x64/0xc0 device_add+0xb38/0xc30 of_device_add+0x64/0x90 of_platform_device_create_pdata+0xd0/0x170 of_platform_bus_create+0x244/0x600 of_platform_notify+0x1b0/0x254 blocking_notifier_call_chain+0x9c/0xd0 __of_changeset_entry_notify+0x1b8/0x230 __of_changeset_apply_notify+0x54/0xe4 of_overlay_fdt_apply+0xc04/0xd94 ... The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680) The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it ! Prevent the out-of-bounds read by copying the device address into a buffer of sufficient size.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-46744
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: Squashfs: sanity check symbolic link size Syzkiller reports a "KMSAN: uninit-value in pick_link" bug. This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk. The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events: 1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size. 2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number. 3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page. This patch adds a sanity check which checks that the symbolic link size is not larger than expected. -- V2: fix spelling mistake.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46745
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Input: uinput - reject requests with unreasonable number of slots When exercising uinput interface syzkaller may try setting up device with a really large number of slots, which causes memory allocation failure in input_mt_init_slots(). While this allocation failure is handled properly and request is rejected, it results in syzkaller reports. Additionally, such request may put undue burden on the system which will try to free a lot of memory for a bogus request. Fix it by limiting allowed number of slots to 100. This can easily be extended if we see devices that can track more than 100 contacts.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46746
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: free driver_data after destroying hid device HID driver callbacks aren't called anymore once hid_destroy_device() has been called. Hence, hid driver_data should be freed only after the hid_destroy_device() function returned as driver_data is used in several callbacks. I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling KASAN to debug memory allocation, I got this output: [ 13.050438] ================================================================== [ 13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh] [ 13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3 [ 13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479 [ 13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0 [ 13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024 [ 13.067860] Call Trace: [ 13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8 [ 13.071486] [ 13.071492] dump_stack_lvl+0x5d/0x80 [ 13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -> 0002) [ 13.078296] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.082199] print_report+0x174/0x505 [ 13.085776] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 13.089367] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.093255] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.097464] kasan_report+0xc8/0x150 [ 13.101461] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.105802] amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.110303] amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.114879] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.119450] sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082] [ 13.124097] hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5] [ 13.127404] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.131925] ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5] [ 13.136455] ? _raw_spin_lock_irqsave+0x96/0xf0 [ 13.140197] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 13.143602] ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b] [ 13.147234] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.150446] ? __devm_add_action+0x167/0x1d0 [ 13.155061] hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172] [ 13.158581] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.161814] platform_probe+0xa2/0x150 [ 13.165029] really_probe+0x1e3/0x8a0 [ 13.168243] __driver_probe_device+0x18c/0x370 [ 13.171500] driver_probe_device+0x4a/0x120 [ 13.175000] __driver_attach+0x190/0x4a0 [ 13.178521] ? __pfx___driver_attach+0x10/0x10 [ 13.181771] bus_for_each_dev+0x106/0x180 [ 13.185033] ? __pfx__raw_spin_lock+0x10/0x10 [ 13.188229] ? __pfx_bus_for_each_dev+0x10/0x10 [ 13.191446] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.194382] bus_add_driver+0x29e/0x4d0 [ 13.197328] driver_register+0x1a5/0x360 [ 13.200283] ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172] [ 13.203362] do_one_initcall+0xa7/0x380 [ 13.206432] ? __pfx_do_one_initcall+0x10/0x10 [ 13.210175] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.213211] ? kasan_unpoison+0x44/0x70 [ 13.216688] do_init_module+0x238/0x750 [ 13.2196 ---truncated---

Published: 2024-09-18Modified: 2026-04-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46747
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-46749
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush() This adds a check before freeing the rx->skb in flush and close functions to handle the kernel crash seen while removing driver after FW download fails or before FW download completes. dmesg log: [ 54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080 [ 54.643398] Mem abort info: [ 54.646204] ESR = 0x0000000096000004 [ 54.649964] EC = 0x25: DABT (current EL), IL = 32 bits [ 54.655286] SET = 0, FnV = 0 [ 54.658348] EA = 0, S1PTW = 0 [ 54.661498] FSC = 0x04: level 0 translation fault [ 54.666391] Data abort info: [ 54.669273] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 54.674768] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 54.674771] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000 [ 54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000 [ 54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 54.710152] Modules linked in: btnxpuart(-) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core sch_fq_codel fuse [ 54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2 [ 54.744364] Hardware name: FSL i.MX8MM EVK board (DT) [ 54.744368] Workqueue: hci0 hci_power_on [ 54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 54.757249] pc : kfree_skb_reason+0x18/0xb0 [ 54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart] [ 54.782921] sp : ffff8000805ebca0 [ 54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000 [ 54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230 [ 54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92 [ 54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff [ 54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857 [ 54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642 [ 54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688 [ 54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000 [ 54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac [ 54.857599] Call trace: [ 54.857601] kfree_skb_reason+0x18/0xb0 [ 54.863878] btnxpuart_flush+0x40/0x58 [btnxpuart] [ 54.863888] hci_dev_open_sync+0x3a8/0xa04 [ 54.872773] hci_power_on+0x54/0x2e4 [ 54.881832] process_one_work+0x138/0x260 [ 54.881842] worker_thread+0x32c/0x438 [ 54.881847] kthread+0x118/0x11c [ 54.881853] ret_from_fork+0x10/0x20 [ 54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400) [ 54.896410] ---[ end trace 0000000000000000 ]---

Published: 2024-09-18Modified: 2024-09-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46750
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: PCI: Add missing bridge lock to pci_bus_lock() One of the true positives that the cfg_access_lock lockdep effort identified is this sequence: WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120 Where pci_reset_bus() users are triggering unlocked secondary bus resets. Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses pci_bus_lock() before issuing the reset which locks everything *but* the bridge itself. For the same motivation as adding: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge); to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add pci_dev_lock() for @bus->self to pci_bus_lock(). [bhelgaas: squash in recursive locking deadlock fix from Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46752
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: replace BUG_ON() with error handling at update_ref_for_cow() Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory).

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46755
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id() mwifiex_get_priv_by_id() returns the priv pointer corresponding to the bss_num and bss_type, but without checking if the priv is actually currently in use. Unused priv pointers do not have a wiphy attached to them which can lead to NULL pointer dereferences further down the callstack. Fix this by returning only used priv pointers which have priv->bss_mode set to something else than NL80211_IFTYPE_UNSPECIFIED. Said NULL pointer dereference happened when an Accesspoint was started with wpa_supplicant -i mlan0 with this config: network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" } When waiting for the AP to be established, interrupting wpa_supplicant with and starting it again this happens: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000 | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18 | Hardware name: somemachine (DT) | Workqueue: events sdio_irq_work | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex] | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157 | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Call trace: | mwifiex_get_cfp+0xd8/0x15c [mwifiex] | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex] | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex] | mwifiex_process_sta_event+0x298/0xf0c [mwifiex] | mwifiex_process_event+0x110/0x238 [mwifiex] | mwifiex_main_process+0x428/0xa44 [mwifiex] | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio] | process_sdio_pending_irqs+0x64/0x1b8 | sdio_irq_work+0x4c/0x7c | process_one_work+0x148/0x2a0 | worker_thread+0x2fc/0x40c | kthread+0x110/0x114 | ret_from_fork+0x10/0x20 | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ end trace 0000000000000000 ]---

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46759
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: hwmon: (adc128d818) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46760
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: schedule rx work after everything is set up Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup. The stack trace looks like this: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on. Fix this by moving the first usb_submit_urb after everything is set up. For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status.

Published: 2024-09-18Modified: 2024-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46761
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel crash when we try to hot-unplug/disable the PCIe switch/bridge from the PHB. The crash occurs because although the MSI data structure has been released during disable/hot-unplug path and it has been assigned with NULL, still during unregistration the code was again trying to explicitly disable the MSI which causes the NULL pointer dereference and kernel crash. The patch fixes the check during unregistration path to prevent invoking pci_disable_msi/msix() since its data structure is already freed.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46762
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Fix possible access to a freed kirqfd instance Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd created and added to the irqfds_list by privcmd_irqfd_assign() may get removed by another thread executing privcmd_irqfd_deassign(), while the former is still using it after dropping the locks. This can lead to a situation where an already freed kirqfd instance may be accessed and cause kernel oops. Use SRCU locking to prevent the same, as is done for the KVM implementation for irqfds.

Published: 2024-09-18Modified: 2024-09-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46763
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fou: Fix null-ptr-deref in GRO. We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. [0] The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol in struct fou. When fou_release() is called due to netns dismantle or explicit tunnel teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data. Then, the tunnel socket is destroyed after a single RCU grace period. So, in-flight udp4_gro_receive() could find the socket and execute the FOU GRO handler, where sk->sk_user_data could be NULL. Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL checks in FOU GRO handlers. [0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou] Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93d ---truncated---

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46765
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ice: protect XDP configuration with a mutex The main threat to data consistency in ice_xdp() is a possible asynchronous PF reset. It can be triggered by a user or by TX timeout handler. XDP setup and PF reset code access the same resources in the following sections: * ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked * ice_vsi_rebuild() for the PF VSI - not protected * ice_vsi_open() - already rtnl-locked With an unfortunate timing, such accesses can result in a crash such as the one below: [ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14 [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18 [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: PTP reset successful [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ +0.000045] #PF: supervisor read access in kernel mode [ +0.000023] #PF: error_code(0x0000) - not-present page [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1 [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021 [ +0.000036] Workqueue: ice ice_service_task [ice] [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice] [...] [ +0.000013] Call Trace: [ +0.000016] [ +0.000014] ? __die+0x1f/0x70 [ +0.000029] ? page_fault_oops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? exc_page_fault+0x7b/0x180 [ +0.000022] ? asm_exc_page_fault+0x22/0x30 [ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice] [ +0.000194] ice_free_tx_ring+0xe/0x60 [ice] [ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice] [ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice] [ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice] [ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice] [ +0.000145] ice_rebuild+0x18c/0x840 [ice] [ +0.000145] ? delay_tsc+0x4a/0xc0 [ +0.000022] ? delay_tsc+0x92/0xc0 [ +0.000020] ice_do_reset+0x140/0x180 [ice] [ +0.000886] ice_service_task+0x404/0x1030 [ice] [ +0.000824] process_one_work+0x171/0x340 [ +0.000685] worker_thread+0x277/0x3a0 [ +0.000675] ? preempt_count_add+0x6a/0xa0 [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50 [ +0.000679] ? __pfx_worker_thread+0x10/0x10 [ +0.000653] kthread+0xf0/0x120 [ +0.000635] ? __pfx_kthread+0x10/0x10 [ +0.000616] ret_from_fork+0x2d/0x50 [ +0.000612] ? __pfx_kthread+0x10/0x10 [ +0.000604] ret_from_fork_asm+0x1b/0x30 [ +0.000604] The previous way of handling this through returning -EBUSY is not viable, particularly when destroying AF_XDP socket, because the kernel proceeds with removal anyway. There is plenty of code between those calls and there is no need to create a large critical section that covers all of them, same as there is no need to protect ice_vsi_rebuild() with rtnl_lock(). Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp(). Leaving unprotected sections in between would result in two states that have to be considered: 1. when the VSI is closed, but not yet rebuild 2. when VSI is already rebuild, but not yet open The latter case is actually already handled through !netif_running() case, we just need to adjust flag checking a little. The former one is not as trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of hardware interaction happens, this can make adding/deleting rings exit with an error. Luckily, VSI rebuild is pending and can apply new configuration for us in a managed fashion. Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to indicate that ice_x ---truncated---

Published: 2024-09-18Modified: 2024-09-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46770
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net//device/reset when reset is in progress try to get coalesce settings using ethtool: # ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46771
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: can: bcm: Remove proc entry when dev is unregistered. syzkaller reported a warning in bcm_connect() below. [0] The repro calls connect() to vxcan1, removes vxcan1, and calls connect() with ifindex == 0. Calling connect() for a BCM socket allocates a proc entry. Then, bcm_sk(sk)->bound is set to 1 to prevent further connect(). However, removing the bound device resets bcm_sk(sk)->bound to 0 in bcm_notify(). The 2nd connect() tries to allocate a proc entry with the same name and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking the original proc entry. Since the proc entry is available only for connect()ed sockets, let's clean up the entry when the bound netdev is unregistered. [0]: proc_dir_entry 'can-bcm/2456' already registered WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375 Modules linked in: CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375 Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48 RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246 RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0 R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fbd708b0e5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040 R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098 R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46773
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check denominator pbn_div before used [WHAT & HOW] A denominator cannot be 0, and is checked before used. This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46776
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Run DC_LOG_DC after checking link->link_enc [WHAT] The DC_LOG_DC should be run after link->link_enc is checked, not before. This fixes 1 REVERSE_INULL issue reported by Coverity.

Published: 2024-09-18Modified: 2024-11-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46777
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: udf: Avoid excessive partition lengths Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46780
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect references to superblock parameters exposed in sysfs The superblock buffers of nilfs2 can not only be overwritten at runtime for modifications/repairs, but they are also regularly swapped, replaced during resizing, and even abandoned when degrading to one side due to backing device issues. So, accessing them requires mutual exclusion using the reader/writer semaphore "nilfs->ns_sem". Some sysfs attribute show methods read this superblock buffer without the necessary mutual exclusion, which can cause problems with pointer dereferencing and memory access, so fix it.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46781
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix missing cleanup on rollforward recovery error In an error injection test of a routine for mount-time recovery, KASAN found a use-after-free bug. It turned out that if data recovery was performed using partial logs created by dsync writes, but an error occurred before starting the log writer to create a recovered checkpoint, the inodes whose data had been recovered were left in the ns_dirty_files list of the nilfs object and were not freed. Fix this issue by cleaning up inodes that have read the recovery data if the recovery routine fails midway before the log writer starts.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46782
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ila: call nf_unregister_net_hooks() sooner syzbot found an use-after-free Read in ila_nf_input [1] Issue here is that ila_xlat_exit_net() frees the rhashtable, then call nf_unregister_net_hooks(). It should be done in the reverse way, with a synchronize_rcu(). This is a good match for a pre_exit() method. [1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16 CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup include/linux/rhashtable.h:604 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620 flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) page_type: 0xbfffffff(buddy) raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000 raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline] get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline] rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini ---truncated---

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46783
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: fix return value of tcp_bpf_sendmsg() When we cork messages in psock->cork, the last message triggers the flushing will result in sending a sk_msg larger than the current message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes negative at least in the following case: 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); // <==== HERE 473 return -EACCES; Therefore, it could lead to the following BUG with a proper value of 'copied' (thanks to syzbot). We should not use negative 'copied' as a return value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46784
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup Currently napi_disable() gets called during rxq and txq cleanup, even before napi is enabled and hrtimer is initialized. It causes kernel panic. ? page_fault_oops+0x136/0x2b0 ? page_counter_cancel+0x2e/0x80 ? do_user_addr_fault+0x2f2/0x640 ? refill_obj_stock+0xc4/0x110 ? exc_page_fault+0x71/0x160 ? asm_exc_page_fault+0x27/0x30 ? __mmdrop+0x10/0x180 ? __mmdrop+0xec/0x180 ? hrtimer_active+0xd/0x50 hrtimer_try_to_cancel+0x2c/0xf0 hrtimer_cancel+0x15/0x30 napi_disable+0x65/0x90 mana_destroy_rxq+0x4c/0x2f0 mana_create_rxq.isra.0+0x56c/0x6d0 ? mana_uncfg_vport+0x50/0x50 mana_alloc_queues+0x21b/0x320 ? skb_dequeue+0x5f/0x80

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46786
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF The fscache_cookie_lru_timer is initialized when the fscache module is inserted, but is not deleted when the fscache module is removed. If timer_reduce() is called before removing the fscache module, the fscache_cookie_lru_timer will be added to the timer list of the current cpu. Afterwards, a use-after-free will be triggered in the softIRQ after removing the fscache module, as follows: ================================================================== BUG: unable to handle page fault for address: fffffbfff803c9e9 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 21ffea067 P4D 21ffea067 PUD 21ffe6067 PMD 110a7c067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G W 6.11.0-rc3 #855 Tainted: [W]=WARN RIP: 0010:__run_timer_base.part.0+0x254/0x8a0 Call Trace: tmigr_handle_remote_up+0x627/0x810 __walk_groups.isra.0+0x47/0x140 tmigr_handle_remote+0x1fa/0x2f0 handle_softirqs+0x180/0x590 irq_exit_rcu+0x84/0xb0 sysvec_apic_timer_interrupt+0x6e/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 default_idle_call+0x38/0x60 do_idle+0x2b5/0x300 cpu_startup_entry+0x54/0x60 start_secondary+0x20d/0x280 common_startup_64+0x13e/0x148 Modules linked in: [last unloaded: netfs] ================================================================== Therefore delete fscache_cookie_lru_timer when removing the fscahe module.

Published: 2024-09-18Modified: 2026-04-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46787
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following race can occur: mfill_atomic other thread ============ ============ pmdp_get_lockless() [reads none pmd] __pte_alloc [no-op] BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.

Published: 2024-09-18Modified: 2024-11-20
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46791
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open The mcp251x_hw_wake() function is called with the mpc_lock mutex held and disables the interrupt handler so that no interrupts can be processed while waking the device. If an interrupt has already occurred then waiting for the interrupt handler to complete will deadlock because it will be trying to acquire the same mutex. CPU0 CPU1 ---- ---- mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlock Use disable_irq_nosync() instead because the interrupt handler does everything while holding the mutex so it doesn't matter if it's still running.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46794
LOW3.3

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. ]

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
References
CVE-2024-46795
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset the binding mark of a reused connection Steve French reported null pointer dereference error from sha256 lib. cifs.ko can send session setup requests on reused connection. If reused connection is used for binding session, conn->binding can still remain true and generate_preauth_hash() will not set sess->Preauth_HashValue and it will be NULL. It is used as a material to create an encryption key in ksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer dereference error from crypto_shash_update(). BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 8 PID: 429254 Comm: kworker/8:39 Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 ) Workqueue: ksmbd-io handle_ksmbd_work [ksmbd] RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? do_user_addr_fault+0x2ee/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] ? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] _sha256_update+0x77/0xa0 [sha256_ssse3] sha256_avx2_update+0x15/0x30 [sha256_ssse3] crypto_shash_update+0x1e/0x40 hmac_update+0x12/0x20 crypto_shash_update+0x1e/0x40 generate_key+0x234/0x380 [ksmbd] generate_smb3encryptionkey+0x40/0x1c0 [ksmbd] ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd] ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd] smb2_sess_setup+0x952/0xaa0 [ksmbd] __process_request+0xa3/0x1d0 [ksmbd] __handle_ksmbd_work+0x1c4/0x2f0 [ksmbd] handle_ksmbd_work+0x2d/0xa0 [ksmbd] process_one_work+0x16c/0x350 worker_thread+0x306/0x440 ? __pfx_worker_thread+0x10/0x10 kthread+0xef/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x44/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46798
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object When using kernel with the following extra config, - CONFIG_KASAN=y - CONFIG_KASAN_GENERIC=y - CONFIG_KASAN_INLINE=y - CONFIG_KASAN_VMALLOC=y - CONFIG_FRAME_WARN=4096 kernel detects that snd_pcm_suspend_all() access a freed 'snd_soc_pcm_runtime' object when the system is suspended, which leads to a use-after-free bug: [ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270 [ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330 [ 52.047785] Call trace: [ 52.047787] dump_backtrace+0x0/0x3c0 [ 52.047794] show_stack+0x34/0x50 [ 52.047797] dump_stack_lvl+0x68/0x8c [ 52.047802] print_address_description.constprop.0+0x74/0x2c0 [ 52.047809] kasan_report+0x210/0x230 [ 52.047815] __asan_report_load1_noabort+0x3c/0x50 [ 52.047820] snd_pcm_suspend_all+0x1a8/0x270 [ 52.047824] snd_soc_suspend+0x19c/0x4e0 The snd_pcm_sync_stop() has a NULL check on 'substream->runtime' before making any access. So we need to always set 'substream->runtime' to NULL everytime we kfree() it.

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46800
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: sch/netem: fix use after free in netem_dequeue If netem_dequeue() enqueues packet to inner qdisc and that qdisc returns __NET_XMIT_STOLEN. The packet is dropped but qdisc_tree_reduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails") Commands to trigger KASAN UaF: ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF

Published: 2024-09-18Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46802
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: added NULL check at start of dc_validate_stream [Why] prevent invalid memory access [How] check if dc and stream are NULL

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46803
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check debug trap enable before write dbg_ev_file In interrupt context, write dbg_ev_file will be run by work queue. It will cause write dbg_ev_file execution after debug_trap_disable, which will cause NULL pointer access. v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL.

Published: 2024-09-27Modified: 2024-10-04
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46804
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add array index check for hdcp ddc access [Why] Coverity reports OVERRUN warning. Do not check if array index valid. [How] Check msg_id valid and valid array index.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46805
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix the waring dereferencing hive Check the amdgpu_hive_info *hive that maybe is NULL.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46806
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix the warning division or modulo by zero Checks the partition mode and returns an error for an invalid mode.

Published: 2024-09-27Modified: 2024-10-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46807
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: Check tbo resource pointer Validate tbo resource pointer, skip if NULL

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46809
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check BIOS images before it is used BIOS images may fail to load and null checks are added before they are used. This fixes 6 NULL_RETURNS issues reported by Coverity.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46810
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ Make sure the connector is fully initialized before signalling any HPD events via drm_kms_helper_hotplug_event(), otherwise this may lead to NULL pointer dereference.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46811
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box [Why] Coverity reports OVERRUN warning. soc.num_states could be 40. But array range of bw_params->clk_table.entries is 8. [How] Assert if soc.num_states greater than 8.

Published: 2024-09-27Modified: 2024-10-07
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46812
HIGH7.8

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.

Published: 2024-09-27Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46814
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check msg_id before processing transcation [WHY & HOW] HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid array index, and it needs checking before used. This fixes 4 OVERRUN issues reported by Coverity.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46815
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[] [WHY & HOW] num_valid_sets needs to be checked to avoid a negative index when accessing reader_wm_sets[num_valid_sets - 1]. This fixes an OVERRUN issue reported by Coverity.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46817
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 [Why] Coverity reports OVERRUN warning. Should abort amdgpu_dm initialize. [How] Return failure to amdgpu_dm_init.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46818
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check gpio_id before used as array index [WHY & HOW] GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore should be checked in advance. This fixes 5 OVERRUN issues reported by Coverity.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46819
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: the warning dereferencing obj for nbio_v7_4 if ras_manager obj null, don't print NBIO err data

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46821
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix negative array index read Avoid using the negative values for clk_idex as an index into an array pptable->DpmDescriptor. V2: fix clk_index return check (Tim Huang)

Published: 2024-09-27Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46822
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed. If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible for the entry in cpu_madt_gicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against the possibility.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46826
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46827
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix firmware crash due to invalid peer nss Currently, if the access point receives an association request containing an Extended HE Capabilities Information Element with an invalid MCS-NSS, it triggers a firmware crash. This issue arises when EHT-PHY capabilities shows support for a bandwidth and MCS-NSS set for that particular bandwidth is filled by zeros and due to this, driver obtains peer_nss as 0 and sending this value to firmware causes crash. Address this issue by implementing a validation step for the peer_nss value before passing it to the firmware. If the value is greater than zero, proceed with forwarding it to the firmware. However, if the value is invalid, reject the association request to prevent potential firmware crashes. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Published: 2024-09-27Modified: 2024-11-20
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46828
HIGH7.8

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.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46829
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: rtmutex: Drop rt_mutex::wait_lock before scheduling rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning. Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop. [ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ]

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46830
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Acquire kvm->srcu when handling KVM_SET_VCPU_EVENTS Grab kvm->srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory. Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN via sync_regs(), which already holds SRCU. I.e. trying to precisely use kvm_vcpu_srcu_read_lock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVM_SET_VCPU_EVENTS. ============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted ----------------------------- include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm] stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x13f/0x1a0 kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel] load_vmcs12_host_state+0x432/0xb40 [kvm_intel] vmx_leave_nested+0x30/0x40 [kvm_intel] kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? mark_held_locks+0x49/0x70 ? kvm_vcpu_ioctl+0x7d/0x970 [kvm] ? kvm_vcpu_ioctl+0x497/0x970 [kvm] kvm_vcpu_ioctl+0x497/0x970 [kvm] ? lock_acquire+0xba/0x2d0 ? find_held_lock+0x2b/0x80 ? do_user_addr_fault+0x40c/0x6f0 ? lock_release+0xb7/0x270 __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539

Published: 2024-09-27Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46832
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed This avoids warning: [ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 Caused by get_c0_compare_int on secondary CPU. We also skipped saving IRQ number to struct clock_event_device *cd as it's never used by clockevent core, as per comments it's only meant for "non CPU local devices".

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46835
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix smatch static checker warning adev->gfx.imu.funcs could be NULL

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46836
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: validate endpoint index for ast udc We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array. Found by static analysis.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46840
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46843
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove SCSI host only if added If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added, set the scsi_host_added flag to true after adding a SCSI host and check whether it is set or not before removing it.

Published: 2024-09-27Modified: 2024-10-08
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46844
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setup_one_line().

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46846
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: rockchip: Resolve unbalanced runtime PM / system PM handling Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it. Also, refactor some of the resume() error handling, because it's not actually a good idea to re-disable clocks on failure.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46848
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Limit the period on Haswell Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW. HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46849
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: axg-card: fix 'use-after-free' Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194

Published: 2024-09-27Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46852
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: dma-buf: heaps: Fix off-by-one in CMA heap fault handler Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dma_buf_mmap_internal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping.

Published: 2024-09-27Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46853
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: spi: nxp-fspi: fix the KASAN report out-of-bounds bug Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated---

Published: 2024-09-27Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46854
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: net: dpaa: Pad packets to ETH_ZLEN When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running $ ping -s 11 destination

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-46855
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_socket: fix sk refcount leaks We must put 'sk' reference before returning.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46857
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix bridge mode operations when there are no VFs Currently, trying to set the bridge mode attribute when numvfs=0 leads to a crash: bridge link set dev eth2 hwmode vepa [ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] [ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core] [...] [ 168.976037] Call Trace: [ 168.976188] [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core] [ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core] [ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0 [ 168.979714] rtnetlink_rcv_msg+0x159/0x400 [ 168.980451] netlink_rcv_skb+0x54/0x100 [ 168.980675] netlink_unicast+0x241/0x360 [ 168.980918] netlink_sendmsg+0x1f6/0x430 [ 168.981162] ____sys_sendmsg+0x3bb/0x3f0 [ 168.982155] ___sys_sendmsg+0x88/0xd0 [ 168.985036] __sys_sendmsg+0x59/0xa0 [ 168.985477] do_syscall_64+0x79/0x150 [ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 168.987773] RIP: 0033:0x7f8f7950f917 (esw->fdb_table.legacy.vepa_fdb is null) The bridge mode is only relevant when there are multiple functions per port. Therefore, prevent setting and getting this setting when there are no VFs. Note that after this change, there are no settings to change on the PF interface using `bridge link` when there are no VFs, so the interface no longer appears in the `bridge link` output.

Published: 2024-09-27Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46858
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: Fix uaf in __timer_delete_sync There are two paths to access mptcp_pm_del_add_timer, result in a race condition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry) In remove_anno_list_by_saddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1). Keeping a reference to add_timer inside the lock, and calling sk_stop_timer_sync() with this reference, instead of "entry->add_timer". Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf.

Published: 2024-09-27Modified: 2025-12-24
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46859
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses The panasonic laptop code in various places uses the SINF array with index values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array is big enough. Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute. Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller. For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these.

Published: 2024-09-27Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-46860
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change When disabling wifi mt7921_ipv6_addr_change() is called as a notifier. At this point mvif->phy is already NULL so we cannot use it here.

Published: 2024-09-27Modified: 2024-10-02
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46861
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: usbnet: ipheth: do not stop RX on failing RX callback RX callbacks can fail for multiple reasons: * Payload too short * Payload formatted incorrecly (e.g. bad NCM framing) * Lack of memory None of these should cause the driver to seize up. Make such failures non-critical and continue processing further incoming URBs.

Published: 2024-09-27Modified: 2024-10-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46863
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-lnl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.

Published: 2024-09-27Modified: 2024-10-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46870
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable DMCUB timeout for DCN35 [Why] DMCUB can intermittently take longer than expected to process commands. Old ASIC policy was to continue while logging a diagnostic error - which works fine for ASIC without IPS, but with IPS this could lead to a race condition where we attempt to access DCN state while it's inaccessible, leading to a system hang when the NIU port is not disabled or register accesses that timeout and the display configuration in an undefined state. [How] We need to investigate why these accesses take longer than expected, but for now we should disable the timeout on DCN35 to avoid this race condition. Since the waits happen only at lower interrupt levels the risk of taking too long at higher IRQ and causing a system watchdog timeout are minimal.

Published: 2024-10-09Modified: 2026-05-05
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-46871
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller number to create array dmub_callback & dmub_thread_offload has potential to access item out of array bound. Fix it.

Published: 2024-10-09Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47658
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: crypto: stm32/cryp - call finalize with bh disabled The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.

Published: 2024-10-09Modified: 2024-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47659
HIGH8.8

In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xHIGH 8.8
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47660
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: fsnotify: clear PARENT_WATCHED flags lazily In some setups directories can have many (usually negative) dentries. Hence __fsnotify_update_child_dentry_flags() function can take a significant amount of time. Since the bulk of this function happens under inode->i_lock this causes a significant contention on the lock when we remove the watch from the directory as the __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask() races with __fsnotify_update_child_dentry_flags() calls from __fsnotify_parent() happening on children. This can lead upto softlockup reports reported by users. Fix the problem by calling fsnotify_update_children_dentry_flags() to set PARENT_WATCHED flags only when parent starts watching children. When parent stops watching children, clear false positive PARENT_WATCHED flags lazily in __fsnotify_parent() for each accessed child.

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47663
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9834: Validate frequency parameter value In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47664
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned.

Published: 2024-10-09Modified: 2024-10-23
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47665
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup Definitely condition dma_get_cache_alignment * defined value > 256 during driver initialization is not reason to BUG_ON(). Turn that to graceful error out with -EINVAL.

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47666
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Set phy->enable_completion only when we wait for it pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash.

Published: 2024-10-09Modified: 2025-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47667
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47668
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path.

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47669
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix state management in error path of log writing function After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang. Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping. Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared.

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47670
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ocfs2: add bounds checking to ocfs2_xattr_find_entry() Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images.

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47671
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-47673
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: pause TCM when the firmware is stopped Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING. bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace: iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30

Published: 2024-10-09Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47674
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling.

Published: 2024-10-15Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47678
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-47679
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47682
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47683
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Recompute DSC Params if no Stream on Link [why] Encounter NULL pointer dereference uner mst + dsc setup. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 [how] dsc recompute should be skipped if no mode change detected on the new request. If detected, keep checking whether the stream is already on current state or not.

Published: 2024-10-21Modified: 2025-12-29
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47684
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47685
CRITICAL9.1

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---

Published: 2024-10-21Modified: 2025-11-18
CVSS 3.xCRITICAL 9.1
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-47686
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-47690
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47691
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) - f2fs_ioc_shutdown - f2fs_do_shutdown - f2fs_stop_gc_thread - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.

Published: 2024-10-21Modified: 2024-10-23
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47692
MEDIUM6.5

In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47693
MEDIUM6.5

In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 6.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47695
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47697
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.

Published: 2024-10-21Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47698
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]

Published: 2024-10-21Modified: 2026-05-05
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47699
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47701
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47704
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47705
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47706
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | Λ | Λ | Λ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1 2) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | Λ \--------------\| | | V V | bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1 3) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> Λ | | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47707
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47710
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47713
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47718
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47720
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47723
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-47727
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix "in-kernel MMIO" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47728
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47730
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47731
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47734
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-47735
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47737
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47738
LOW3.3

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xLOW 3.3
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
References
CVE-2024-47739
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47740
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47742
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47743
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47745
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47747
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47748
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47749
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47750
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47751
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-47752
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.

Published: 2024-10-21Modified: 2024-10-22
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47753
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47754
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-47757
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-49850
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string "0" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49851
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49852
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees "nport". But then we dereference "nport" on the next line which is a use after free. Re-order these lines to avoid the use after free.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49853
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49854
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix uaf for accessing waker_bfqq after splitting After commit 42c306ed7233 ("block, bfq: don't break merge chain in bfq_split_bfqq()"), if the current procress is the last holder of bfqq, the bfqq can be freed after bfq_split_bfqq(). Hence recored the bfqq and then access bfqq->waker_bfqq may trigger UAF. What's more, the waker_bfqq may in the merge chain of bfqq, hence just recored waker_bfqq is still not safe. Fix the problem by adding a helper bfq_waker_bfqq() to check if bfqq->waker_bfqq is in the merge chain, and current procress is the only holder.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49855
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49856
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49858
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49859
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49860
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-49861
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
References
CVE-2024-49863
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49866
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49867
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---

Published: 2024-10-21Modified: 2026-01-05
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49868
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49870
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49871
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49875
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
References
CVE-2024-49877
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49878
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM".

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49879
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49881
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49882
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49883
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49884
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49886
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49889
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49890
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49892
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49894
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49895
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49896
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49900
HIGH7.1

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.1
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
References
CVE-2024-49901
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/

Published: 2024-10-21Modified: 2024-10-25
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49902
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49903
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49905
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49907
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing "dc" to "dc->hwss.apply_idle_power_optimizations", which dereferences null "dc->clk_mgr". (The function pointer resolves to "dcn35_apply_idle_power_optimizations".) This fixes 1 FORWARD_NULL issue reported by Coverity.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49912
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49913
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49924
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49925
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49927
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49929
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49930
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49931
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Published: 2024-10-21Modified: 2024-10-25
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49933
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49935
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 : mov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 : lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49936
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49937
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a "WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49938
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49939
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49944
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49946
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49948
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49949
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49950
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49951
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49952
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49954
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49955
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49957
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49958
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49959
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49960
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49961
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49962
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49963
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49965
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series "Misc fixes for ocfs2_read_blocks", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49966
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49969
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49973
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49975
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49978
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49981
HIGH7.0

In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.0
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49983
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49985
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49986
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49987
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: "Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined." To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.

Published: 2024-10-21Modified: 2024-10-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49988
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.

Published: 2024-10-21Modified: 2024-10-28
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-49989
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49991
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49992
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49996
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-49997
HIGH7.5

In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.5
CVSS:3.x/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
References
CVE-2024-50000
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50001
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50002
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50003
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50006
MEDIUM4.7

In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 4.7
CVSS:3.x/CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50007
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-50008
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan->tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50012
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50013
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50015
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.

Published: 2024-10-21Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-50179
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.

Published: 2024-11-08Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-53144
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE This aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4 ("Bluetooth: Always request for user confirmation for Just Works") always request user confirmation with confirm_hint set since the likes of bluetoothd have dedicated policy around JUST_WORKS method (e.g. main.conf:JustWorksRepairing). CVE: CVE-2024-8805

Published: 2024-12-17Modified: 2025-11-03
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-57947
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_set_pipapo: fix initial map fill The initial buffer has to be inited to all-ones, but it must restrict it to the size of the first field, not the total field size. After each round in the map search step, the result and the fill map are swapped, so if we have a set where f->bsize of the first element is smaller than m->bsize_max, those one-bits are leaked into future rounds result map. This makes pipapo find an incorrect matching results for sets where first field size is not the largest. Followup patch adds a test case to nft_concat_range.sh selftest script. Thanks to Stefano Brivio for pointing out that we need to zero out the remainder explicitly, only correcting memset() argument isn't enough.

Published: 2025-01-23Modified: 2025-12-06
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-58087
HIGH8.1

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix racy issue from session lookup and expire Increment the session reference count within the lock for lookup to avoid racy issue with session expire.

Published: 2025-03-12Modified: 2026-04-23
CVSS 3.xHIGH 8.1
CVSS:3.x/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
References
CVE-2024-58239
MEDIUM5.5

In the Linux kernel, the following vulnerability has been resolved: tls: stop recv() if initial process_rx_list gave us non-DATA If we have a non-DATA record on the rx_list and another record of the same type still on the queue, we will end up merging them: - process_rx_list copies the non-DATA record - we start the loop and process the first available record since it's of the same type - we break out of the loop since the record was not DATA Just check the record type and jump to the end in case process_rx_list did some work.

Published: 2025-08-22Modified: 2025-11-26
CVSS 3.xMEDIUM 5.5
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
References
CVE-2024-58240
HIGH7.8

In the Linux kernel, the following vulnerability has been resolved: tls: separate no-async decryption request handling from async If we're not doing async, the handling is much simpler. There's no reference counting, we just need to wait for the completion to wake us up and return its result. We should preferably also use a separate crypto_wait. I'm not seeing a UAF as I did in the past, I think aec7961916f3 ("tls: fix race between async notify and socket close") took care of it. This will make the next fix easier.

Published: 2025-08-28Modified: 2026-01-09
CVSS 3.xHIGH 7.8
CVSS:3.x/CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References